Forem: jas'scyberspace

walkthrough 1

jas'scyberspace — Fri, 29 Aug 2025 14:47:18 +0000

What is path traversal?

Path traversal is when someone can manipulate a file path to break out of the folder they’re supposed to be limited to. Instead of just accessing a safe file, they can reach other parts of the server and potentially view or change files they shouldn’t have access to. That means things like app data or behavior can be altered just by tweaking the path.

Walkthrough: Simulating Path Traversal on My Site

Now that we’ve got a basic understanding of what path traversal is, let’s walk through a real-world(ish) example. I intentionally added this vulnerability (a safe and fun version) to my site, l1nuxbutt3rfly (https://l1nuxbutt3rfly.squarespace.com/), it’s both a portfolio and an experimental space where I practice and document real-world cybersecurity scenarios. This walkthrough is part of my ongoing project to simulate realistic vulnerabilities in a safe, controlled environment.

Here’s how I recreated a classic path traversal bug using a custom download button and a bit of creative URL manipulation:

Basically, the download feature doesn't properly clean up what the user types into the URL, so you can trick it into grabbing files it shouldn’t. Instead of just giving you a safe file, it lets you “traverse” up directories and access other stuff—like hidden flags or system files—by using ../ in the path.

How the Path Traversal Works on My Site

The fake “Download” button you see is tied to a URL that includes a query string like this:

/downloads?token=pt-demo

On the surface, it just looks like a normal link to a downloadable file. But behind the scenes, it mimics a common web application mistake: trusting user input in the file path.

Step-by-Step Breakdown

The Setup
I placed a link on the site that mimics a typical file download endpoint. It uses a token parameter that appears to validate access to a specific file—something like a brochure, .zip file, or demo content.

The Simulated Mistake
Instead of restricting access to just one file, the URL accepts manipulated paths. The idea is to simulate an application that takes whatever path the user supplies (in the query) and serves it back without sanitizing or validating it.

The Exploit
By tweaking the token parameter, you can simulate a traversal attack. For example, you might change it to:

/downloads?token=../../../../secret/flag.txt
This tricks the server into “walking up” the file tree and accessing something outside the intended directory. In this case, it simulates grabbing a hidden flag file.

The Flag Reveal
If done right, instead of a clean download, you get access to the simulated "flag" file, which represents unauthorized access to sensitive data—just like in a real path traversal attack.

How to Prevent This

Sanitize Like You Mean It

Never trust user input. If someone gives you a file name or path, clean it like it’s radioactive. Strip out characters like ../, backslashes, or anything that screams “I’m trying to break out of this folder.”

Think of it like giving a guest access to your living room, not the keys to your bedroom, kitchen, and locked drawer full of secrets.

Use Whitelisting

Only allow access to specific, known-good files or paths. If it’s not in your approved list, don’t even consider serving it.

Lock Down Your Directories

Set strict permissions on your server. Even if someone does try path traversal, they should hit a dead end—preferably a big bold 403 Forbidden wall.

Monitor & Alert

Add logging and alerts for weird file path activity. If someone’s tossing around a lot of ../, it’s not because they’re lost.

Use Built-In Path Libraries

Languages like Python, Node, and others have safe ways to resolve file paths (e.g., path.resolve() in Node.js). Don’t reinvent the wheel—use tools that help block sneaky behavior.

Building an Azure Misconfiguration Scanner: Starting Over

jas'scyberspace — Thu, 31 Jul 2025 13:54:34 +0000

I am learning Azure security architecture, IAM, and policy-driven detection by completing a 90-Day challenge to build an Azure Misconfiguration Scanner.

I'm breaking things, detecting misconfigurations, and building a tool to find them. Until I really broke something—my Azure account.

What Happened

At the end of July, I hit a wall working on day 8 tasks. What started out as a learning exercise quickly turned into an Azure tenant lockout.

After completing most of the tasks for day 8, my Azure account hit a critical issue. I attempted to clean up some identify settings in Entra ID which led to me accidentally removing my access and changing the login identify. While I can login to the account, I can no longer:

Assign permissions
Contact support through the portal
Disable or modify active, assigned policies

It feels like a ghost tenant.

Starting Over

Rather than waste time contacting support (which I will eventually have to do), I created a new Azure account where I have a new subscription and tenant. I rebuilt everything I had done in the first eight days in one focused sprint.

I have successfully:

Assigned Audit NICs with Public IPs policy and Audit Storage Public Network Access policy
Created Test Resource Groups with and without policy and a public storage account
Deployed a non-compliant NIC to validate detection
Verified results using 'az policy state list' and CLI filters
Detected and confirmed compliance using CLI outpu t

az policy assignment create \
    --name "AuditStorage PublicAccess" \
    --policy "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf801975c4c" \
    --params "{ \"listOfAllowedLocations\": { \"value\": [\"eastus\"] } }" \
    --scope "/subscriptions/<new-sub-id>/resourceGroups/RG-SecureAccess"

Changes

I decided to make and stick to a few changes that will help this second time around. I am designating a review day after 1 full week is completed. I will not edit user principal names and now confirm Owner access on correct subscriptions before assignments. Lastly, I keep a dedicated RG-PolicyExempt group to simulate misconfigs freely. These changes exposed a few lessons I needed to learn about myself while working on this project which includes policy fatigue, avoid lockouts, role clarity, and testing safely.

Have you ever completely locked yourself out of a cloud environment? Or made any critical mistakes on a production level environment? Did it set you back or push you forward? Comment below.

Building an Azure Misconfiguration Scanner: Week 1 of My 90-Day Challenge

jas'scyberspace — Wed, 30 Jul 2025 17:36:46 +0000

TL;DR

“I wanted to learn Azure security in a way that certifications alone couldn’t teach me—by breaking things, detecting misconfigurations, and building a tool to find them.”

Week 1 was baseline setup + first policy detection
Hit CLI/PowerShell quirks and Azure Policy delays
Repo + workflow started coming together
Next week → storage misconfigurations + tenant chaos

This is Week 1 of my 90-Day challenge to build an Azure Misconfiguration Scanner while deeply learning Azure security architecture, IAM, and policy-driven detection. With the help of James Lee's AZ-104 Course, Microsoft Learn, and ChatGPT, I am learning and building.

Azure security concepts often make sense on paper, but in practice, misconfigurations happen fast. So instead of passively studying, I:

Created an Azure security lab from scratch
Intentionally misconfigured resources
Detected those misconfigs with Azure Policy + automation
Built toward a custom misconfiguration scanner by Day 90

Week 1 Goals

Set up a baseline Azure environment
Understand Azure Policy basics
Trigger the first noncompliance detection
Start organizing everything in a GitHub repo

What I Accomplished

✅ Created Resource Group RG-SecureAccess as my main test scope
✅ Built test users, groups, and a custom insecure RBAC role
✅ Learned how to assign built-in Azure Policies
“Network interfaces should not have public IPs”
✅ Created a misconfigured NIC to test detection
✅ Saw Azure Policy deny a VM creation (cool moment!)
✅ Started repo scaffolding with queries/nics-with-public-ips.cli

Early Struggles

Azure CLI vs PowerShell quoting: Multi-line CLI commands and JSON parameters broke constantly until I learned to use JSON files for parameters.
Azure Policy evaluation delay: I expected instant results but policies take ~5-10 minutes to evaluate resources.
Tenant confusion (EXT# accounts): Guest vs. internal accounts behave differently for RBAC & CLI. I hit weird auth issues early on but didn’t know they’d come back to bite me harder in Week 2.

Hands-On Example

Here’s the CLI command I used to create a policy that

 az policy assignment create `
   --name "AuditStoragePublicAccess" `
   --display-name "Audit public network access on storage accounts" `
   --policy e56962a6-4747-49cd-b67b-bf8b01975c4c `                                                       
   --params '{\"listOfAllowedLocations\":{\"value\":[\"eastus\"]}}' `      
   --scope "/subscriptions/5d4b8df0-f30a-4bc3-b350-1ace90d201b8/resourceGroups/RG-SecureAccess"

Then, I had to create a storage account with public access enabled to trigger the policy violation

az storage account create `
  --name "publicstoragedemo$((Get-Random -Maximum 9999))" `
  --resource-group "RG-SecureAccess" `
  --location "eastus" `
  --sku "Standard_LRS" `
  --kind "StorageV2" `
  --allow-blob-public-access true `
  --public-network-access Enabled

*Follow me here if you want to see how this experiment evolves weekly.
*

Series Index

Week 1: Baseline Setup & First Detection
Week 2: Learning Azure Security the Hard Way
(Week 3 coming soon: Key Vault misconfigurations)