Embrace The Red

Today I’m gonna talk about a class of application security issues I ran across a few times over the years. In particular, let’s discuss race conditions when it comes to files with sensitive content and permissions.

Race conditions can allow an adversary to gain access to sensitive information on machines. Assume a system creates a file that contains sensitive information and afterwards applies permissions to lockdown that file.

Understanding the race condition

Let’s look at a practical example seen in the wild a few times. Imagine code like this:

These days business decisions and feature development often is influenced heavily by telemetry information. Telemetry is baked into the programs, services and applications we use.

Companies are hungry for telemetry because with machine learning and Deep Neural Networks “data is the new oil”.

Telemetry provides insights into how users use a particular system, what features they exercise, how they configure the system, what errors they trigger and what buttons they like clicking on.

Throughout my career I have been fascinated with quality assurance and testing, especially security testing and red teaming. One discussion that comes up frequently is how to measure the maturity of such programs and processes.

My answer is straight forward as there are already existing frameworks that can be leveraged, adjusted and borrowed from to fit the needs of offensive security programs.

You are likely familiar or have at least heard of the Capability Maturity Model Integration from Carnegie Mellon University. In particular CMMI defines five levels to measure software engineering processes as follows:

In this post I will discuss some testing techniques for internal red teams to identify privacy issues in services and infrastructure, most importantly a simple three step approach that might uncover interesting results.

Background story

First, let me share a story from the past. When I did my master’s I built an app that performs end to end encryption of Facebook posts. This means that only the intended audience for which your posts were encrypted for can decipher the posts.

Finally I got to writing some basic tooling for invoking the Firefox debugging API to send commands to the browser and read the responses. This can be useful for grabbing cookies in the post-exploitation phase.

It works for Windows and macOS, should also work on Linux.

This technique is probably most useful when we don’t have root or the user’s credentials to decrypt cookies or can’t attach a regular debugger to the browser process.

Previously I talked about remotely debugging Chrome, and we also covered the latest Microsoft Edge browser along the way.

These features allow an adversary to gain access to authentication tokens and cookies. See MITRE ATT&CK Technique T1539: Steal Web Session Cookie as well for this.

What about Firefox?

For a while I was wondering if (my favorite) browser Firefox has such debugging features as well, and how one could detect malware trying to exploit it.

A technique on Windows that is less known is how to do basic port-proxying.

Proxying ports is useful when a process binds on one (maybe only the local) interface and you want to expose that endpoint on another network interface.

Let’s say you have an existing process that listens only on the loopback interface, and you want to expose it remotely. Or there are two network interfaces and you want expose traffic from one to the other (maybe some evil persistence for port 3389) - or think of basic pivoting.

Amazon Bug Bounty!

Great news: Amazon is now offering bounties via a security vulnerabiltiy research program

Bad news: AWS is out of scope!

When I read this I remembered that a few years ago I found persistent Cross-Site-Scripting on the AWS Console.

This post is a write up on how I found the XSS back then, techniques I used and how they evolved over the years and Amazon’s response.

AWS Console and Cross Site Scripting

The story is that I had just created an AWS account and started using the service.

I’m excited that Feedspot ranked this blog (Embrace the Red) the number #10 pentest blog out there.

Subscribe and check-in regularly for new content related to offensive security engineering, penetration testing and red teaming.

You can also follow me on Twitter @wunderwuzzi23.

Cheers.

A few months ago we discussed the importance of performing active credential hunting for your organization.

This is to ensure clear text credentials in widely accessible locations and source code are identified before an adversary gets a hold of them.

In this post we will explore using built-in operating system indexing features to search for information on machines quickly.

Many of us use the indexing features (like Windows Search and Spotlight) daily via the UI.

The Shadowbunny TTP in the PenTest Magazine

The latest edition of the PenTest Magazine features an article of mine about using virtual machines (VMs) during lateral movement to establish persistence and evade detections.

A few years back when I came up with the idea of using VMs for lateral movement during red teaming, I called it the Shadowbunny TTP and that name stuck around in my head. There is more info in the article around the origin of the name also.

Some organization have this interesting concept of a bug jail to prevent new feature development when there are too many existing flaws in the system.

For instance, if an engineer has 5 or more bugs assigned they aren’t allowed to work on anything else but fixing their bugs.

What is the Security Bug Jail?

A security bug jail goes along the same lines. The owner of a system can never have more than a certain upper limit of active security bugs.

Monte Carlo simulations can be a useful tool to uplevel your red teaming skills and provide a different and fresh perspective for highlighting, discussing and presenting findings.

Red teaming is about challenging an organization. This includes analyzing business processes and methodologies, including our own.

Obviously, using Monte Carlo simulations in the security realm is not my idea. I first ran across the idea in Hubbard’s book about measuring cybersecurity risk. Since then I have been thinking and playing around with applying these methods to security program’s, especially red teaming and threat modeling.

The results of phishing campaigns are often not comparable with each other over time. Various security vendors and red teams use different tooling and techniques - which is totally fine.

However, I recommend requiring tracking a minimum set of metrics to be able to compare results over time.

Funny side facts: At times employees are messing with the red team, entering invalid creds for CISO or CEO and things along those lines. Some employees (often engineers) are curious and open the link in isolated VMs to debug and explore the phishing site.

Last month I did some research on Firefox, specifically I was learning more about it’s remote debugging features. As part of that I was reading Bugzilla bug information and learned more about Mozilla’s infrastructure.

One thing I noticed reading up on details was that Mozilla uses Phabricator.

What is Phabricator?

Phabricator is a collaborative web-based toolset for code reviews, checkins, bugs, work items, wiki, pastes, credentials and many other useful things. It was orginally developed by Facebook as far as I know.

Revisiting Cookie Crimes

In 2018 @mangopdf described “Cookie Crimes”, which is great research around Chrome’s remote debugging feature that allows adversaries and malware to gain access to cookies quite convienently during post-exploitation.

The original research is published here, and it still works today.

The new Microsoft Edge browser and Chromium

Microsoft’s latest Edge browser is based on the same code, Chromium. I guess, you already know where this is going now…

Chrome’s remote debugging feature enables malware post-exploitation to gain access to cookies. Root privileges are not required. This is a pretty well-known and commonly used adversarial technique - at least since 2018 when Cookie Crimes was released.

However, remote debugging also allows observing user activities and sensitive personal information (aka spying on users) and controlling the browser from a remote computer.

Below screenshot shows a simulated attacker controlling the victim’s browser and navigating to chrome://settings to inspect information:

Adversaries are leveraging widely exposed clear text credentials to gain access to sensitive information.

At times the term “harvesting credentials” is used when red teamers emulate these attacks - which is something that appears to be more opportunistic and I would propose that security teams start to actively hunt for credential exposure that can put their organization at risk – in case you are not yet doing that.

Actively hunting for credential exposure

The idea of credential hunting is targeted and focused, leveraging intelligence about systems and combing it with powerful search techniques to identify exposure.

Conceptual Attack Graphs

One question that I have gotten a few times about “Cybersecurity Attacks - Red Team Strategies” is around the conceptual attack graphs in “Chapter 3, Measuring an Offensive Security Program”. Specifically, how I create them.

In this post I will briefly go over some of the reasons for creating them, and also how I create them and share a template for others to use and adjust.

I’m not a graphic designer, so I’m sure there are better ways of doing this.

Announcement

After countless evenings and weekends in coffee shops, and multiple vacations with the laptop, I’m excited to announce that my first book has been published. It took 18 months from writing the first words (at Victrola Coffee Roasters on Capitol Hill by the way) to finishing this project just a few days ago.

Looking back its amazing how this all came together. The first intial draft had 100 pages, and in the end it ended up being 524 pages.