I documented putting this site together. I go back to it at times to look at a few things because I do want to set things up with Let’s Encrypt again and I don’t remember it all.

I also found out that over the past couple of weeks my domain would go away. I use CloudFlare for DNS and would check what was going on. It always gave this .dev domain a different IP then https://youat.dev which is weird because they are running on the same server, behind the same IP.

I would run my ddclient script and it would tell me things were set properly and was being skipped.

Then I would go to CloudFlare and see that the IP for themonkeyplayground.dev was set different than youat.dev The IP looked familiar too, but I couldn’t put two and two together.

Why was one updating correctly and not the other?

I find in cases like this, it’s usually me, not the system. Yes, the system or automation is great to shake my fist at, but it’s how I use it that is what matters.

Do you remember testing the ddclient script on my always VPN’d box? Me neither, but I did write about it, because it bit me during testing.

Yup. I ran into the issue when I was running it on my VPN’d machine for testing. I knew it would bite me if I had to do it again, so I tried to save myself and maybe anyone who caught the post a bit of pain. Go me!

But, I did forget to kill it on my other machine so I am thinking I was having a whole bunch of competing updates to my DNS. One from the machine serving the web site and the other from where I tested it. I’ve disabled and removed the script from the machine that shouldn’t be doing the updating and all has been working as expected.

What did I learn? Automation works. Documentation saves ones butt and when troubleshooting – check the user first… even (especially) if that user is me.

I’ve been playing around in HTB and root-me.org to help me learn the skills I need to do my job. And also, because figuring things out is fun! I have people that I work on these with to learn what I don’t know and get better at what I do know.

These are all great places. The issue I am coming up against is I can’t share what I have done to work through most of these challenges. Yes, when working on a team, we can share to get the results we need, but when I am working it out, I can’t write it out for others for later. This is what we do in the real world when we get a good solution.

Root-me does give the option to share how it was done afterward, which I think is a great idea. I can even see what others had done to get the answer. I learned the other day after using Dominic Breuker’s stego-toolkit, that just running a file through strings would have gotten me the results with a lot less resources and time. I can’t complain, because I learned a lot and will come back to use the toolkit. Plus, it looked real cool to me when it did work with the toolkit.

Tonight I worked for a few hours on a HTB web challenge that probably would take most people a good 10-15 minutes. I used three different tools, googling and looking back on notes about the options to use – but I got the result I was looking for. I can’t say much past that though without breaking the rules.

And that is where the problem is starting to lie. I need to find a way to share what I have done – without breaking the rules of the game. Even though the game is about breaking the rules.

I can write it up for myself. I will write it up for myself, because I will forget it if I don’t. But, I didn’t do it all on my own. No, I didn’t get the answer from a web site. I got direction from other people’s posts or man pages based on info gathering from the challenge.

Let’s see if I can break it down a bit – simply.

The name of the challenge is usually a good hint at some way to start. Googling the name led me to a tool to use — a brute force password tool.

Before I could use that tool though I needed to know what I was looking at. That let me try Burp Suite. I can say I used Burp Suite ’cause with a web attack I think that’s the go to tool. One I don’t have a lot of experience with, but here’s a good chance to get some.

Got my parameters and got my data, now onto the tool with so many options. Struggling to get the parameters correct took the longest amount of time.

Get that! I’m golden.

Nope. I’m not. It even tells me so. I get the password for the site – but just get told I am too slow. The site password is not the flag.

Fair enough, I’ve been there before. I’ve faced off against Candy in the root-me.org programming challenges. I think I can outsmart this if I need to be quick. That just means don’t do it manually.

A few minutes later, with a refresher on -d 'param=value' -X POST and I get the flag.

It’s a small victory, but a learning experience. A learning experience I can only vaguely share about before giving away too much in an information gathering challenge.

Of course I have.

So have you. In some way or another a company has flubbed and let someone else get your information. That information may be my credentials or personal data, but it’s out there somewhere; usually through our email address. A quick search on Google News will show how often it happens.

Have I Been Pwned? is a great resource to check what data and what services are leaked so we can fix it. It’s kinda like the WebMD of personal info. Lots of info. Much concern after looking at it.

The site provides an API for a geek like me (or a system admin in need of a quick way to regularly check on users) to look up the emails we use to sign in to so many sites and see if they have been compromised. I have used recon-ng, which has a great module for checking against HIBP, but I really don’t want to fire up my VM just to do some checking of the family emails.

This is where the hibp_quickCheck was born. I put together a python script that will query the API for a single email or a batch of them, check a breach or a paste and let the runner know where each email stands.

The simplest check is for one email and a breach:

./hibp_check.py breach -e [email protected]

This will come back with any breach info on the email provided. An important thing to note is the Breach Date. Was the breach last week or 5 years ago? What can I do to help myself? Am I still using the account? Have I changed the password?

Checking a paste is just as important as a breach. A paste is telling us that a password or hash may actually be out there, not just that it happened.

Now, if I want to use either of these with a list of emails for my family let’s say (or an org) – I just put the list in file, one email at a time and run:

./hibp_check.py breach -f /path/to/file

We will get a list for each email in the file. The API has a rate limit, so if there are a lot of emails in the list, it can take some time. I have tried to take this into account when choosing a file to go through.

My hopes is this can help out geek families and a sys admin or two.

Grab the script from my GitHub repo: https://github.com/m0nkeyplay/hibp_quickCheck

What are we doing here? (and where is here?)

Here – in a secret basement buried in snow, somewhere in the Midwest, with no redundant power supply, on a RaspberryPi with another site or two… behind CloudFlare… in hopes to keep things going… we are building a website dedicated to trying things, breaking things, learning things and documenting it all!

When the lights are on I will be writing up tests I am doing, issues I run into while testing security software, or just learning how to hack things a little better. I find WordPress a better solution to do this then my homegrown site.

I have also set up a collaborative site for people to share what they are doing to help ourselves and to help others. Same server. Let’s see if it all holds!

I hope you and I both find this site useful.