You can see the end in sight! #Hacking #Google episode 5 challenge 2 threw a difficult curve-ball at me - a cryptographic challenge!

In the past, I avoided these challenges on CTFs, assuming it's unlikely I'll be able to break them.

But since this #CTF explores beginner-friendly challenges, I decided to give it a go, and after some work (a tad longer than the previous challenges), I managed to solve it!
(Using another great blog for help).

The full write-up:
https://taltechtreks.com/2024/11/27/hacking_google_ep005_challenge_02.html

Did you think I forgot? Nope!

After a short hiatus for the #DEFCON watch-party, #HackingGoogle #CTF posts are back with the first challenge of the last episode!

In this one - did you forget to feed your Tamagotchi? Because it returned for revenge on this challenge, reborn from the egg on this image file manipulation challenge.

Full write-up on the blog: https://taltechtreks.com/2024/11/20/hacking_google_ep005_challenge_01.html

In the past two weeks, right after DEFCON uploaded the videos for this year’s talks, I decided to not procrastinate as I usually do. Instead, I sat down, watched the talks, and made a short summary of each. I believed (and still strongly do) that it’s a sure way to embed the unique ideas and techniques presented into my head.

Well, writing things is something I’ve always done—the hard part for me is posting them online. So, I decided this time I’ll tackle this by posting the summaries over LinkedIn and other networks.

Easier said than done. Limiting the amount of time between consecutive posts was the key here — the pressure made it so I wasn’t able to endlessly pass my text through various LLM models.

At the end, almost all posts are basically the first iteration with a simple grammar and spell-checker applied. At some point, I even built up enough courage to tag the amazing researchers!

So all in all, I think I can crown this experiment a success. I’m happy I did it and can’t wait for next year’s talks, because even if I don’t attend, I’ll have my summaries to look forward to!

Thanks go yet again to the amazing presenters and to everyone who has been diligently reading these posts and approaching to me about them :)

All the posts can be found, in order, on my blog: https://talsk.github.io/2024/11/13/DEFCON-32-Solo-Watch-Party.html

-13-

Splitting the Email Atom: Exploiting Parsers to Bypass Access Controls - Gareth Heyes

Understanding email addresses is hard. Why? While the first emails were sent in the '70s, to this day it's a wildly popular way to communicate. The form of how email addresses look has been continuously appended throughout the years.

This means that today, valid addresses are defined according to half a dozen different RFCs. Usually, that doesn't bother the average programmer, as servers implementing SMTP (most common email protocol today) will parse the address properly and route it to the correct destination.

The problem arises with the (relatively recent) rise of Single Sign-On (SSO). With this technology, you can sign into Website A using your account on Website B (you've probably seen a "Sign in with Google/Apple/Microsoft 365/..." option in the past).

In many cases, sites like Website A need to understand what organization the user belongs to — so they are correctly attached to and can access their organization.

The solution to this? Extract the domain part of the email address! This makes sense as it's a strong indicator for the user's organization.

However, now we might have a problem: there are two separate systems parsing the email address — the SMTP protocol (routing the address according to specifications), and a developer parsing the domain out of the email (probably with a copy-pasted regex and code).

Discrepancies between the two could easily lead to cases where a new email address is associated with a victim organization while being routed to an attacker-controlled domain — and this is what Gareth exploited. In the talk, he covered three discrepancies:

Using these three techniques along with some other niche features of email addresses, Gareth was able to access private GitLab Enterprise servers, Zendesk organizations, bypass cloud GitHub email verification, domain-protected Cloudflare instances, and even steal CSRF tokens from Joomla by embedding an XSS in registered users' email addresses!

To tie it up, Gareth focuses on methodology. It's not simple bypassing parsers you can't see, using so many different combinations of potentially vulnerable features.

The methodology is great in general for all research; I recommend watching the talk and taking away from it.

https://www.youtube.com/watch?v=JERBqoTllaE

#DEFCON #vulnerability #email

-12-
Secrets and Shadows: Leveraging Big Data for Vulnerability Discovery at Scale - @bill

In an engaging and flowing talk, Bill presents a mind-opening new approach for discovering organizations that are susceptible to security issues. Those traditionally found manually, by leveraging access to big data or large-scale search.

The talk explores two such issues: dangling DNS issues in cloud providers, and exposed long-lived credentials.

Dangling DNS vulnerabilities happens when a domain is associated with a temporary IP address assigned to a cloud compute instance, such as EC2. If the compute resource goes down, the IP is released and other cloud users can "catch" it by spinning up their own compute resource, hijacking the domain in the process.

This can allow an attacker to steal session tokens and cookies, execute malicious scripts on users, and deny service.

Traditionally, an attack would target a specific domain and try to capture its associated IP address. However, Bill utilized a different approach — continuously reallocate cloud resources to enumerate massive amount of IPs!

Using a service that maps IP addresses back to domains, Bill simply spun up a lot of machines, allocating IP addresses, and catching their associated domains in the process! In total, 54K unique second-level-domains were captured!

An issue here was a limitation on the number of machines and IP addresses the cloud tenant was able to acquire. Using some neat tricks, Bill was able to bypass these restrictions in both AWS and GCP.

Going back to exposed long-lived credentials, a classic issue at this point, where many online services allow creation of such credentials that too often end up in public places through committed code, environment variables, and files.

There have been multiple researchers utilizing big data search to find such exposed credentials through public code searching utilities. However, nowadays many code platforms block these credentials on commit, so this method is not as useful.

So what's the new idea here? Utilize search engines on other kind of data to find those secrets! Namely, Bill used websites like VirusTotal that index many files and executables, while also supporting YARA rules to quickly search through them all.

Bill created rules to detect known static credential types based on prefixes, and found 16,652 validated credentials ranging from OpenAI API keys to AWS and GCP keys, and also Stripe secrets.

A unique case of how researching known issues from a different perspective can yield amazing results.

#DEFCON #bigdata #aws #gcp

https://www.youtube.com/watch?v=-KXgcWuv-Ug

-11-

SQL Injection Isn't Dead: Smuggling Queries at the Protocol Level - @pspaul

SQL injection attacks exploit vulnerabilities in web applications that fail to properly sanitize user input, allowing attackers to inject malicious SQL code into database queries.

In the past, they were as prevalent as can be when it comes to web app vulnerabilities, but recent advances in web servers' default configurations and protection mechanisms have made them harder to exploit. This is evident by their ranking in the well-known OWASP Top 10 project.

However, in this talk, Paul shows an exciting new avenue for these vulnerabilities — attacking the underlying protocol!

When it comes to databases today like PostgreSQL, MySQL, Redis and MongoDB, servers communicate with them over the wire using a binary protocol. This binary protocol is TLV-based: first, the type of message, then its length, and finally, the value. So your SQL query is actually embedded within such a "packet".

While these binary protocols are commonplace in web servers' communication with peripherals, Paul focused on databases, and specifically how the length field of a message is handled by libraries when it receives a very large message, namely, more than the size that could fit in a 32-bit field.

He discovered that prominent open-source packages handling connecting and querying PostgreSQL and MongoDB, upon receiving a message longer than 232 bytes, calculate the length of the message correctly while truncating it to 32-bit before writing the length field.

This means that a message just over 232 bytes arrives at the database prepended with a length field which is very small, leaving the rest of the message to be accidentally parsed as packets! This gives a theoretical attack full control over queries.

While data exfiltration is almost not possible (the application usually returns the result of the first query), attackers can simply add a new user with high privileges to the database and use it to steal data.

On discovery, Paul wasn't satisfied with the vulnerability's exploitability — a potential attacker wouldn't know exactly the server's query and where the malicious payload is embedded, they have to send multiple 2GB queries, making the exploit very long and noisy. Through some nice tricks, borrowed from the world of shellcodes, he managed to reduce the attack process to at most 2 tries!

This research avenue still has a lot of possibilities open — Paul only scratched the surface. Binary protocols are used extensively for communication with many other applications like logging, storage, queues and caches. Even for databases — just a subset were inspected.

An enlightening talk, showing how produce it can be to take an approach and techniques used in one area of vulnerability research (in this case HTTP desync attacks by James Kettle) and applying it to a completely different domain.

#DEFCON #databases #sqli #vulnerability

https://www.youtube.com/watch?v=Tfg1B8u1yvE

-10-
Grand Theft Actions: Abusing Self-Hosted GitHub Runners at Scale - Adnan Khan, John Stawinski

GitHub Actions is a CI/CD tool that lets you run code (workflows) in response to events. Being code and all—it needs something to run on.
The default option is GitHub runners - an ephemeral VM. Another option, more commonly used for large repos, is self-hosted runners— bringing your own machine to run workflows on.

Self-hosted runners are a security nightmare. Clearly shown throughout this talk, the main issue is that they’re persistent, so any vulnerability in self-hosted workflows is amplified.

Jumping ahead, the talk presents many attack techniques against self-hosted runners, nicely concluded by John in this diagram: https://github.com/jstawinski/Github-Actions-Attack-Diagram

The research found vulnerabilities in dozens of high profile orgs, but the talk itself focuses on PyTorch. So what’s the recipe for hacking into self-hosted runners?

First: become a contributor. The default config only blocks first-time contributors from running workflows, so after the first approved PR— it's a free game.
Find a simple grammar mistake and fix it in a quickly accepted PR, becoming a contributor in the process. From then on, you can run workflows on the self-hosted runner using PRs from your fork.

Then, gain persistence: since the machine might be protected, the researchers take a safe approach and deploy another self-hosted runner agent that connects to a private repo. Neat!

Next, steal GITHUB_TOKEN— a secret allowing access to GitHub for the workflow. However, in fork PRs these have read only access. But, workflows share the self-hosted runner, so after gaining persistence access they simply stole a GITHUB_TOKEN from another workflow from the base repo.

With such a token, there are many options for supply chain attack, like changing release assets!

But it wasn’t enough for Adnan and John— they wanted to steal real secrets from workflows. These would most likely escalate their privilege into the PyTorch organization.

It only takes compromising one workflow using these secrets. But, the already-compromised workflow did not use them, and the stronger GITHUB_TOKEN cannot modify the workflows directory.

The solution is simple— they found a workflow depending on a Python code from outside the workflow directory. Now, all that's needed is use GITHUB_TOKEN to create a branch, add a payload to the Python code that dumps the secrets to logs, trigger the workflow with the, and retrieve the secrets from the logs.

The stolen secrets contained a GitHub personal access token with wide access to PyTorch’s private repos, as well as an AWS access key with highly privileged access to PyTorch’s AWS account.

And, just like that, becoming a contributor with a simple PR led to full compromise of PyTorch’s GitHub and AWS, which could have led to catastrophic consequences had it not been for this research. Amazing work!

https://www.youtube.com/watch?v=5P7KatZBr_I

#DEFCON #vulnerability #GithubActions #Github

-9-
QuickShell: Sharing is Caring About an RCE Attack Chain on Quick Share - Or Yair, Shmuel Cohen

In this talk, Or and Shmuel take us through a wild adventure that ends up in an RCE attack chain on Quick Share.

Recently, Android’s Quick Share (analogous to Apple’s AirDrop) was released as a tool to Windows machines, marking an easier target for vulnerability research.

And indeed, the researchers found some - few by fuzzing (sending random data following the Quick Share protocol hoping for a crash) and the rest manually. Here are 4 of them:

While interesting vulnerabilities (specifically 3 and 4), none seem to pose a huge risk to Quick Share clients, right?

Well— through an absolutely genius chaining of these primitives, the researchers were able to convert them into a full RCE!

First, they combined 4 and 1— by crashing Quick Share after the client connects to the attacker’s WiFi AP, it persisted forever and was not terminated. Luckily, Quick Share is scheduled to restart every 15 minutes, making the crash only temporary.

Using MitM, an attacker can see metadata of the client's encrypted TLS sessions to detect when the victim is downloading an executable installation file, like VSCode or Spotify — the ClientHello reveals the domain the victim browses to, and the size of the TCP session reveals when a file of a certain size was downloaded.

Why is this useful? Well, primitive 3 enables creation of files in the machine’s “Downloads” folder, the same one Chrome uses for its own downloads. Using the above, an attacker detects when an executable is downloaded and quickly writes a file with the expected name in the folder, while Chrome uses a temporary file during download, causing an unsuspecting victim to run malicious executable!

Where does the last primitive come into play? Turns out that when Chrome finished downloading the file, it actually overwrote the file created by Quick Share. By utilizing primitive 2, Quick Share continuously opens the malicious file, which caused Chrome to give up on overwriting it, while it did delete the temporary file and reported that the download was successful!

This is an absolutely crazy chaining of primitives to achieve this very nice RCE attack flow on victims. Showing how even those that are not deemed not critical to fix might pose a huge risk on victims. Props to the researchers!

https://www.youtube.com/watch?v=wT9gyOeN6zY

#DEFCON #vulnerability #quickshare

-8-

Why are you still using my server for your internet access - Thomas Boejstrup Johansen

Ah, WPAD — now that's a name I haven't heard in a long time.

Short for "Web Proxy Auto-Discovery", WPAD is a protocol for machines on local networks to get their proxy configuration. Invented by Netscape in 1996, this protocol has been deprecated for a LONG time — in 1999, today marking its 25th anniversary.

WPAD is pretty simple — it uses the network name of the user's machine to search for a wpad.dat file, going from more specific to broad. For example, if the network name is pc.team.dep.org.com, a WPAD implementation will try to fetch wpad.team.dep.org.com/wpad.dat, wpad.dep.org.com/wpad.dat and wpad.org.com/wpad.dat in order as long as the last one wasn't found.

wpad.dat is a Proxy Auto-Config (PAC) file - a JavaScript file running in a limited environment. It implements a function that takes a URL and decides on the proxy server for the request (or DIRECT, for no proxy).

So why is this interesting? It happens that many implementations do an additional step, stripping the domain all the way to wpad.com/wpad.dat.

This is on the public internet! Thus this implementation takes a PAC file from a stranger and uses it as the device's proxy configuration.

Luckily, notable WPAD TLDs — com, org, and net — are protected and cannot be registered. However, others are fair game!

In his excellent talk, Thomas reveals that he was able to register wpad.dk (the TLD for Denmark) alongside a few more.

He set up a simple PAC file directing all traffic back to p.wpad.dk, with interesting information like the domain, private and public IP addresses of the client. The proxy always responds with an error message, while Thomas was able to record details about the access.

Here's the stats: 90K requests a day, totaling a whopping 1.1 billion (!!) requests in a year. They span the entire world but mostly from Europe.

The HTTP GET requests were made to many file extensions, like thousands of credentials and over half a million executables. About 200k URLs also included credentials in parameters! Interestingly, the server has received POST requests too, with their entire body!

The clients' User-Agents show how the WPAD issue is not solely a Microsoft problem but spans almost every possible client in existence — Linux, Apple, and many distinct applications are affected.

During his research, Thomas also looked at wpad.dat files on other TLDs, finding some suspiciously malicious — one redirecting unencrypted requests through their proxy, and another one stealing ad requests, possibly for revenue theft!

The talk is great, containing hilarious tidbits about the research and the feedback form on the proxy. These vulnerabilities display both the ingenuity of researchers and the difficulty of fully deprecating a problematic service once it's deeply ingrained in systems.

#DEFCON #wpad #vulnerability #proxy

https://www.youtube.com/watch?v=uwsykPWa5Lc

-7-

Outlook Unleashing RCE Chaos: CVE-2024-30103 & CVE-2024-38021 - Michael Gorelik, Arnold Osipov

Sometimes, a vendor releases a patch fixing a vulnerability you are working on. Disappointing, isn't it?

In this talk, Michael and Arnold show how they turned two patches for Outlook issues back into vulnerabilities!

First, the focus is Outlook custom forms — a feature allowing creation of tailored messages in emails.

Under the hood, forms are COM objects, defining a new form type means creating a config file for it, with a value copied to the registry specifying the COM server handler for it.

So, what if we make the key point at some DLL that we control? That's immediately RCE! To block this, Outlook uses a denylist that filters out registry keys allowing RCE like inprocserver32, localserver, etc.

A vulnerability from earlier this year found the denylist matching fails if you specify an absolute path rather than a relative path (so a \CLSID\...\inprocserver32= is a-okay!). This allows hijacking any COM object in the registry. Luckily, this vulnerability has been patched. But, remember the premise of the talk?

The patch disallowed starting the path with a backslash. So what did Michael and Arnold do? Add a backslash at the end! This works because RegCreateKeyExA deletes the last backslash in the path. However, this happens after the denylist check, which passes and so we have a vulnerability!

Second, the talk looks at Outlook Moniker objects—those are "smart links" in Outlook, allowing you to send emails embedding special links like Ca lender invites, Excel files, etc.

Being simple pointers, it is possible for malicious actors to send emails with references to remote files, potentially leaking NTLM credentials if the user clicks them. Fortunately, Outlook blocks these links.

Unfortunately, earlier this year it was found that if you add an exclamation mark (!) at the end of the link, Outlook blocking won't work.

The reason is a bit complicated, but in short—the link is being treated as a special kind of Moniker, triggering a different flow composed of a few functions, which are vulnerable to remote file access.

This vulnerability was patched by installing a hook on a certain vulnerable function at the end of the flow. The hook checks if a certain flag is set, and if so, blocks the call. The flag is set at the beginning of a function earlier in the flow. So only when the two functions are chained, the call is blocked.

Notice the issue? If another Moniker-related flow eventually reaches the vulnerable function without passing through the first one, the flag isn't set and the patch won't work!

Indeed, the researchers discovered such a flow—a link within an image tag instead of a hyperlink

While a bit convoluted for someone who hasn't touched COM objects for at least a decade, this is still an eye-opening talk on the possibility of finding vulnerabilities in patches.

https://www.youtube.com/watch?v=GwwxeY11xMI

#DEFCON #Vulnerability #Outlook