On June 9, 2021, NetSPI Security Consultant Jake Karnes was featured in a SecureAuth article:
In December 2020, another Kerberos authentication vulnerability was made public, the Kerberos Bronze Bit Attack(CVE-2020-17049). Jake Karnes, Managing Consultant at NetSPI revealed his research after Microsoft released a patch to fix it. The Kerberos Bronze Bit attack was named in the spirit of the widely known Golden Ticket and Silver Ticketattacks and exists in the way the Key Distribution Center handles service tickets and determines whether or not they can be used for delegation.
Let’s start with some Kerberos fundamentals. In general terms, delegation refers to the ability of a service account to act on behalf of a user account to access resources with the access privileges of the latter. The most common example is a web application impersonating a user when it accesses a backend database and retrieves some data under the user’s authority.
Microsoft offers two types of delegation: without restrictions, known as Unconstrained Delegation, and restricted to only certain services, which comes in two flavors: Constrained Delegation and Resource-Based Constrained Delegation. The Kerberos protocol, by itself, doesn’t have the ability to restrict delegation to a specific group of services. For this reason, Microsoft implemented two extensions that allow achieving this behavior: Service for User to Self (S4U2self) and Service for User to Proxy (S4U2proxy).
The Bronze Bit Attack uses both protocols. First, it obtains a service ticket for a targeted user to a compromised service via S4U2self. Then, it tampers this service ticket modifying the forwardable flag. With this tampered ticket, it uses S4U2proxy to obtain a service ticket for the targeted user to the targeted service. Finally, with the last service ticket, the attacker can impersonate the targeted user.
So, surely you are wondering why is this possible? The answer: the forwardable flag is only protected by encrypting the service ticket with the first service’s password hash. If an attacker manages to compromise this service, it’s game over (unless you’re patched). They will be able to decrypt the ticket and flip the flag bit.
@jakekarnes42 used Impacket for the attack implementation and opened the pull request (PR) #1013 that added a new force-forwardable flag to getST.py. Thanks Jake, for using Impacket for this great implementation of the attack!
If you are interested in knowing more details about this, you can check this great series of posts from Jake here: overview, theory and exploitation.
There’s much to learn when it comes to financial sector cybersecurity. People are often surprised to learn the primary mission of the Secret Service is financial crime investigations. The Secret Service was set up right after the Civil War in the Treasury Department to investigate counterfeit currency. So, anytime you read about, North Korean money laundering or ransomware attacks or a bank hit by Russian cybercrime cartel, the people investigating those crimes are Secret Service special agents, not the FBI.
Fun facts aside, financial sector security is a very difficult artform. While financial institutions arguably have some of the best security in the world, they are also being targeted by nation-states and the most advanced cybercrime cartels across the globe. I recently joined NetSPI managing director Nabil Hannan on the Agent of Influence podcast to explore the current state of the financial services threat landscape and share advice on how to protect against today’s adversaries.
Now in its fourth year, my research paper, Modern Bank Heists 4.0, takes the pulse of the evolving cybersecurity threats facing financial institutions in 2021. From my interviews with 126 financial sector CISOs, there were a number of findings that are quite problematic. In this year’s survey, we saw:
A 57 percent increase in wire transfer fraud. A majority realized that the most advanced adversaries weren’t targeting the wire transfer systems themselves, they were looking at targeting nonpublic market information or market strategies of the financial institution.
A 118 percent increase of destructive attacks. Adversaries dropped ransomware in systems but did not ask for ransom, instead dropping wipers in systems to cripple those devices, and manually deleting logs or manipulating the value of time to disrupt the operations of the institution.
38 percent of those surveyed experienced an increase in island hopping, outside of the SolarWinds incident.
Financial industry cybersecurity professionals have their work cut out for them. To help prioritize security efforts, in this blog, I’ll share opportunities to prevent cybercrime in today’s environment and improve your security posture.
First, from the consumer perspective, here are five tips to avoid becoming a victim of financial fraud:
Anytime someone is requesting information from you of any sensitivity, double check the headers, the reply to, and the return path. If it does not match, you’re dealing with an imposter.
Update your critical applications and your operating systems every Tuesday night. That’s when Silicon Valley pushes out its critical updates.
Regardless of the type of device you have, including iOS and Apple devices, you need next generation antivirus or an endpoint protection platform (EPP) to secure it.
Always use two-factor or multi-factor authentication.
If you’ve been compromised or if you see a persistent presence on your device, understand that all of your passwords have been compromised and need to be changed.
To protect against island hopping or supply chain attacks (i.e., SolarWinds), reinforce your defensive security posture.
The SolarWinds breach was a wakeup call. It was a nation-state campaign that required hundreds of cybersecurity criminals to create the myriad of malicious code that was used to attack their constituency. They compromised the trust aspects of the signed certificate associated with the update for SolarWinds’ software to get their initial foothold, then moved laterally in a very elegant fashion, from manipulating timestamps to using steganography to deploying secondary command and control on sleep cycle, the list goes on.
With this concept of island hopping, you need to have the conversation with your board and C-suite to come to an understanding that it’s not about whether your crown jewels are going to be compromised, it’s a question of whether your infrastructure will be commandeered to attack your constituency – that’s what we’re trying to prevent.
To accomplish an effective defensive posture and countermeasures against supply chain attacks, there are a few tactics to deploy. First, conduct regular, weekly cyber threat hunts in your environment to try to identify behavioral anomalies before they manifest. Second, conduct a penetration test from inside out to understand the attack path that an adversary would leverage through your infrastructure to attack your constituency or your partners. Third, pursue the promise of rugged coding and test all code in production for exploitation [note: OWASP testing is fundamental]. You should never release code unless you’ve tested it for exploitation prior to going live.
Lastly, in today’s world we are dealing with four nation states that are actively pursuing and targeting corporations, including software vendors. Information sharing with government agencies is fundamental because it is a bi-directional flow. The work that CISA, the Secret Service, and FBI do to engage and provide you with a heads up on cybercrime trends is imperative to understand when you’re dealing with a supply chain challenge where nation states are working to colonize the environment.
As the attack surface expands amid the pandemic, it is essential to achieve a secure hybrid cloud.
During the pandemic, many financial institutions were required to adopt some sort of cloud computing to support remote work. This increased the attack surface – and adversaries took advantage of that.
When you think of public cloud, think of it like this: You recently moved into a condominium complex. Not all HOA’s [public cloud providers] are equal in terms of how they secure that building, or how they work with the police in that neighborhood, nor how they control access to your floor or unit. People [organizations] must be responsible for the security of their own apartment [data, network], and should be conscious of what their neighbors [third-party partners] are doing. If they’re acting maliciously, they’re putting you in danger.
Yes, the public cloud can enhance your security posture, especially for small businesses. But, for medium sized or large corporations the best path to pursue is that of hybrid cloud. It allows you greater capability to secure yourself against various attacks. However, many do not leverage workload security in hybrid environments. To get started, here are three considerations for securing the hybrid cloud:
Those who follow the cloud security models espoused by the NIST or the NSA have been the most successful.
Those who have truly mobilized and enabled workload security and protection had a better chance of stopping many of today’s attacks.
Do not over rely on Kubernetes to manage and protect containers and instances of containers. Embrace new forms of container security as hackers begin to push the envelope now on what can be done with container stuffing, container attacks, and the misuse of Kubernetes to leverage payloads.
A Bloomberg Intelligence report forecasts cybersecurity spend to exceed $200 billion a year by 2024, driven by “faster-than-expected adoption of cloud-based security.” Further, Gartner says that the proportion of IT spend moving to the cloud will increase in the aftermath of the pandemic. Not to mention spending on cloud infrastructure such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and others reached $39.9 billion in the fourth quarter of 2020 – up $10 billion from 2019.
Simply put, cloud is top of mind for all security professionals today as it is a natural way to increase capacity or deploy projects in this new realm. The increased emphasis on cloud can be attributed to the pandemic-driven demand to support remote working and learning, ecommerce, content streaming, online gaming, and collaboration, according to Canalys.
As cloud adoption accelerates (and shows no signs of slowing), there is no better time to take a deeper look at common cloud security challenges and learn how to modernize your cloud penetration testing efforts to mature your cloud security program effectively and efficiently.
5 common cloud security challenges and risks
Managing cloud workloads deployed outside traditional security governance processes. Access to entire technology stacks is available to anyone with only a credit card swipe. This access to technology outside of your security governance processes, or Shadow IT, depends solely on the awareness of that business unit of the security needs of those projects. If you can identify workloads that were deployed outside of your IT environment, you can test the disparate environment to gain some level of assurance that it was deployed securely while supporting a business unit with unique needs that may not be available from the traditional IT programs.
Resource asymmetry between attackers and defenders. Attackers are limited to only their persistence when attacking your cloud environment. On the other hand, security teams are constrained by budget limitations, resource constraints, and the myriad of other challenges. Cloud configuration assessments informing a penetration test gives you the ability to identify issues that an attacker could identify but in an efficient way that maximizes your investments.
A simple error can have a catastrophic impact. Traditional IT infrastructures are notoriously slow to adapt to innovation but have the benefit of several layers of defense. Infrastructure-as-Code delivers entire data center capabilities in a Python script but one minor error in the deployment can provide direct, internet-facing access to your environments.
The cloud is evolving, and attackers are identifying novel attacks faster than the security industry is able to protect the attack surface. Cloud environments can be very complex and providers like AWS, Azure, and Google Cloud release new capabilities so often it’s difficult for security to keep up. For example, in April 2021, AWS posted nearly 200 announcements about new capabilities, services, features, and region expansions. 200 announcements in a single month. There are not enough people with tenured, seasoned experience in deploying cloud workloads to do it securely. It’s no surprise that cloud security topped ISC2’s list of most important skills needed to pursue a cybersecurity career.
Lack of awareness that cloud security follows the shared responsibility model. It is right to trust cloud providers to secure aspects of your workloads, however, your security team also maintains significant responsibility for security as you migrate to the cloud. This concept is the shared responsibility model, and it varies by provider and service type. Defining you and your providers’ responsibilities is imperative for reducing the number of, and criticality of, vulnerabilities introduced into your cloud environments. You can review the shared responsibility models for Microsoft, Amazon, and Google Cloud online.
AWS shared responsibility model
How to modernize your cloud penetration testing efforts with configuration review
It can be difficult to understand the difference between testing an application that is hosted in a cloud environment and testing the environment in which an application is hosted. Both are vital.
While network penetration testing and application penetration testing focus on identifying vulnerabilities on a particular series of assets within an environment, cloud penetration testing requires a different approach. Because the cloud is an environment itself, it is important to also look at the infrastructure supporting the environment, not solely the applications and assets deployed as a part of the workload. Not only are you testing workloads; you need to also identify issues inherited from parent subscriptions such as elevated IAM privileges or privileged access to sensitive systems and/or data.
Most organizations are testing cloud environments the same way they’ve been testing for years, resulting in a massive gap in attack surface visibility. If an organization truly wants comprehensive testing, a focus on cloud configuration should be a large component of your cloud penetration testing strategy.
A configuration review is used to inform a penetration test. If you were to approach cloud penetration testing the way you approach traditional application or network penetration testing, you would be blind to the configuration of the platform.
An analogy that works well to explain configuration review is a doctor’s visit. If you want a doctor to identify what is wrong with you in an hour-long visit, you’d have to inform them of your symptoms, medical history, recent activity, etc. Without the background information on your health, it would require excessive time and resources to run blood tests, x-rays, etc. to get the information needed to identify what the potential issue is. A configuration review is similar in that it gives pentesters the ability to identify root issues in an efficient way, the same way a malicious attacker would over the course of months – or years. It allows pentesters to act as closely to an attacker as they can within the parameters of your security budget.
Configuration reviews also allow testing teams to provide context to penetration test findings. Say you misconfigured a storage bucket. With a greater understanding of the configuration issues, you gain insight into the root cause of critical vulnerabilities caused by the misconfiguration. For example, “we found an issue with this storage bucket which allowed us to exploit _____ during the penetration test.”
Another emerging concept within modern cloud penetration testing is continuous testing and monitoring. Cloud environments are ephemeral (have a short lifecycles) – so, we often hear the question: how helpful is the information from a cloud penetration test if the environment keeps changing? If you are reviewing the configuration of your cloud platform to support penetration testing efforts, you’ve set the foundation for cloud security success. To address the ephemeral nature of the cloud, more frequent tests and continuous monitoring of the attack surface is a key tactic to stay on top of newly introduced vulnerabilities.
Final thoughts
Now is a better time than any to rally your security testing and cloud teams together to talk about what cloud testing means for your organization. When configuration review is included, cloud penetration testing allows you to not only test for vulnerabilities, but also develop an inventory of your cloud workloads, understand what data is in those workloads, and develop your testing plan for cloud-based applications.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
Name
Domain
Purpose
Expiry
Type
YSC
youtube.com
YouTube session cookie.
52 years
HTTP
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Name
Domain
Purpose
Expiry
Type
VISITOR_INFO1_LIVE
youtube.com
YouTube cookie.
6 months
HTTP
Test
test.com
Testing
7 days
HTTP
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
We do not use cookies of this type.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
We do not use cookies of this type.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
We do not use cookies of this type.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Cookie Settings
Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.
Back
