DEV Community: Austin Hunt

A Security Analysis of a Sassy Quarterback

Austin Hunt — Thu, 27 Oct 2022 01:22:11 +0000

There are a multitude of articles, videos, infographics, and probably even poems out there on the internet walking through the differences between the three main cloud service delivery models. In fact, Google kindly let me know that there are “About 11, 800,000 results” for the query “iaas saas paas”, which, in my head, reads as “Yass, sass! Pass!”

That's exactly what an excited wide receiver yells at a quarterback who just said something sassy to an opposing linebacker. If you needed a way to remember these models, you’ve got it now.

I do plan to provide some background context around the Infrastructure-as-a-Service, Platform-as-a-Service, and Software-as-a-Service delivery models for those reading who may not be familiar with those concepts, but I also intend to take a more specific look at that sassy quarterback with a focus on security.

Since these three models are often represented together in the form of a pyramid with IaaS at the base, PaaS in the middle, and SaaS at the top, and that pyramid serves a semantic purpose, this article will follow that representation, starting with the pyramid’s base: IaaS.

Infrastructure-as-a-Service (IaaS)

With the IaaS model of cloud service delivery, a vendor (e.g., Amazon) provides fundamental building blocks of compute, storage, and networking resources, and the customer, who can access those resources on-demand over the internet, pays for those resources as they use them. The cloud provider, or vendor, is primarily responsible for maintaining the underlying hardware infrastructure to support the service, and the customer has full control to spin up virtualized resources like virtual machines (VMs) with desired amounts of CPU and RAM, volumes for extended storage, databases for an application that may need to store data, load balancers to balance web traffic across a cluster of other VMs for high availability, and even firewalls for controlling and filtering out unauthorized network traffic from their environment. Creativity and money are ultimately the limiting factors in what can and cannot be built by a customer leveraging infrastructure as a service, sort of like how creativity and time left until bedtime are the limiting factors for a kid with a box of LEGOs — build what you want. To give a quick plug, I’m currently using Linode’s LEGOs — I mean IaaS — to host my portraiture portfolio website https://sketchyactivity.com. I was previously using Heroku (which is PaaS, to be discussed next), but they are introducing new costs starting in November so I wanted to move to a service with more stable pricing and a greater degree of flexibility.

Extending upon IaaS is the wonderful concept of infrastructure as code (IaC), which is documented well by Red Hat. With IaC, we take our ability to provision resources in the cloud on-demand with IaaS, and we do it automatically by writing code that hits APIs offered by the IaaS provider (using API keys to authenticate and authorize). While this might not seem too valuable if you only need to spin up one constant virtual machine for a lightweight app or service, IaC can be a major asset if the resource requirements for your app change over time. After all, elasticity is one of the fundamental benefits provided by cloud computing since being able to programmatically scale resources up or down depending on demand also means you are paying only for resources you need over any given time period. Using IaC also means you can house infrastructure configuration in version control, which comes with its own universe of benefits.

Now, IaaS certainly offers a great deal of flexibility and freedom, which really is powerful, but with that power comes with responsibility, as stated by Peter Parker’s Uncle Ben in his well-known 2002 Ted Talk.

IaaS vendors, like all cloud service providers, treat security as a shared responsibility meaning they will maintain the security of physical infrastructure up to the hypervisor (their software running virtual machines) but customers building their own infrastructure with IaaS are responsible for making that build secure as well as making the policies and governance around its management secure. This includes but is not limited to:

Frequently and regularly updating VMs — this is the easiest one, but it’s often forgotten
Following the principle of least privilege, e.g., not using a root user for daily tasks on VMs, or setting up RBAC to provide your internal team with limited access only to what they need to manage infrastructure
Requiring that anyone accessing and managing infrastructure with IaaS is using MFA to log in
Not hardcoding or storing secret values in version control, e.g., API keys for the IaaS API if using IaC; this one’s generally applicable
Disallowing root login and password authentication for SSH; use key-based authentication instead.
Setting up a firewall that allows only the traffic required to provide your service to intended audiences
Setting up monitoring and alerting about system resources to stay updated on the state of your infrastructure
Setting up a CI/CD pipeline for software being deployed on the infrastructure which includes automated testing
Setting up redundant infrastructure as well as backups for recovery in case of failure; make sure to test both to ensure you can meet your recovery time objectives (RTOs) and recovery point objectives (RPOs)
Reviewing audit logs to monitor IaaS activity
Setting up encryption — at rest or in transit, or both, depending on your needs; this may include setting up and regularly renewing your own SSL certificates, e.g., with Let’s Encrypt
Reviewing your specific compliance requirements and configuring your system to meet those

In short, IaaS is the most flexible cloud service delivery model, but it also requires the most time and attention to maintain a secure environment. IaaS may look like the cheapest option based simply on the pay-per-use costs listed by IaaS vendors, but it inherently comes with more security risks for the IaaS customer (and potentially the customer’s customers) since the customer owns such a hefty portion of the shared responsibility. Because of this, IaaS is a more appropriate fit for teams who are trained on and experienced in configuring, managing, maintaining, patching, and generally securing servers at a low level. Without that experience, the business risk likely is much more expensive than the low pay-per-use cost of some virtual machines, and a different delivery model may be a better fit, which leads us to PaaS.

Platform-as-a-Service (PaaS)

As we move up the cloud pyramid that I referred to before into the middle layer of PaaS, the space available shrinks a bit compared to the IaaS base — that’s some basic pyramid geometry for you. In the smaller space of the PaaS layer, we have less freedom but also less responsibility for security as the customer.

The purpose of PaaS is to narrow the scope of customer responsibility in such a way that it simplifies the process of developing and deploying software. In other words, the customer is given a platform on which to work around which guardrails are put in place by the vendor, and the space beyond the guardrails is the vendor’s responsibility.

The customer may, on occasion, linger at the edge of the platform, lean on a guardrail, and stare longingly into that great beyond, but the convenience of clicking a button to deploy their app will beckon them back inward.

The customer can build and deploy application resources and manage data without having to tinker with and configure underlying infrastructure which means rather than having the low-level responsibilities of keeping a server updated and locked down with attention to all the requirements previously discussed, they can put more focus on the application itself — the business logic, the improvements for end users, new features, etc. Since I’m a big fan of analogies, think of it this way: on one hand, someone is offering you — at a low price — a toolbox filled with tools that only work if you put time into consistently repairing them after using them. They work great so long as you maintain them, and you can build a ton of stuff, but if you forget to maintain them, the things you build will collapse and potentially hurt someone, which is quite risky for you especially since you’ve never had to maintain some of these tools. That’s IaaS. Now, on the other hand, someone is offering you, at a higher price, a small pouch of tools that they’ve approved for your use, with the guarantee that they will be responsible for maintaining the tools. You can’t build as much, sure, but you don’t have to spend hours maintaining your tools to make sure what you build works properly and doesn’t hurt anyone. You get to just use them. All you need to focus on is the structural integrity and security of the things you build. That’s PaaS. As a PaaS customer, you still have sort of a building-block-based approach to setting up your environment; the difference is that the building blocks presented as options tend to be a bit less granular and based more on pricing tiers like “Free”, “Production”, “Advanced”, and “Enterprise”, where the price for each tier increases significantly, as they do for Heroku. The general idea is that, as a customer, you can choose pre-configured resources for data storage and computation with varying degrees of capacity and security depending on your specific requirements (where bigger requirements = bigger price), you pay for those resources at intervals, and you use them to build and run your application(s) freely without concern for what’s underneath. Also, not only is each resource you select pre-configured, but all the resources selected are pre-integrated automatically by the platform which means you don’t (generally) need to troubleshoot communication problems between things like databases and web services. In my experience using Heroku, using PaaS simplifies collaboration with other developers, setting up CI/CD pipelines, auto-scaling based on demand, configuring dev, test, and prod environments for a given app, monitoring app activity, managing SSL, and even setting up integrations with other services. These benefits are significant but it’s worth noting that they come at the expense of your wallet and your ability as a developer to easily port your app to another platform. This is because each PaaS provider’s “building blocks” are unique to them as a provider and sometimes can even come with configuration requirements that introduce a need to modify your application code. Once you’ve started depending on a feature set offered exclusively by one vendor, moving elsewhere even in the face of increased pricing or service decline becomes less practical, which is why vendor lock-in is a common problem experienced by PaaS customers.

Now, I’ll put my security glasses back on (I lost them before but found them in my safe; that’s a security joke) and we can look at PaaS from the perspective of security requirements. We’ve established that PaaS customers have a smaller share of the shared responsibility than IaaS customers, and PaaS providers take on that extra responsibility of managing underlying infrastructure. Even with that, PaaS customers are still responsible for:

Analyzing their own compliance requirements and selecting pre-configured resources that meet those requirements (e.g., selecting an environment that runs in network isolation on dedicated resources versus one that is publicly accessible and runs on shared resources). This includes looking at encryption requirements — does the platform encrypt data at rest?
Setting up monitoring and alerting about problems with their application(s)
Configuring role-based access control within the platform (i.e., who can deploy, add new collaborators, manage application data, purchase new resources, delete existing resources, etc.)
Setting up a CI/CD integration with automated tests that must pass before new application versions are deployed by the platform
Monitoring activity of collaborators with access to the platform
Ensuring platform-related configuration variables are not stored in version control or publicly available (e.g., credentials for pre-configured databases); the same applies to any other secret values
Requiring all team members with access to the platform to use MFA to log in (assuming that’s an option)
Establishing a plan for when there is a service outage; this includes having a migration plan either to another PaaS vendor or to some other environment
Staying on top of the quality of their own software (obviously, but it felt wrong to omit this)
Configuring and renewing SSL certs via the platform if applicable
Staying on top of payment and payment-related warnings that could affect your service
Monitoring the service quality of the provider should also be considered a responsibility of the customer; even vendor lock-in mentioned previously can be considered a security threat to your business, especially if the provider significantly changes pricing models (starts robbing you because they can) or their infrastructure quality declines causing unavoidable outages.

With these requirements in mind, the PaaS model is a decent choice for teams of developers who aren’t too proficient with server management, configuration, and security patches but do want some flexibility in the development, testing, and deployment of their service.

In a nutshell, PaaS allows us to hand over a suitcase of low-level responsibilities and freedoms from our IaaS years in exchange for a pricey Gucci bag of guardrailed guarantees of infrastructure security, convenience, and refocused energy on our own applications over which we still have full control.

That brings us to SaaS.

Software-as-a-Service (SaaS)

You’ve made it to the apex of the cloud pyramid. Congratulations! Can you see your attack vectors from here? To access this final delivery model (well, final for this article; there are actually more), we had to submit our technical exploration license to a troll who guards the Bridge of SaaS.

“You have not the right to low level mods,” he said, “but these wares of soft have provisions broad.”

After recovering from the profundity of his trollish poetry and dropping the weight of more security responsibilities at his feet, we were off.

With SaaS, we (the customer) are not developing, building, or deploying a service. Rather, a vendor is delivering some application or service over the internet which we, as customers with internet connections, can access and consume on-demand. We’re talking Microsoft 365 apps like Word, OneDrive, and Teams, Google apps like Gmail, Drive, and Docs, and so on. There’s generally no need to install or maintain any software as a SaaS end user aside from a web browser, which means you are free from all complex software and hardware management. The vendor (e.g., Microsoft or Google to follow the previous examples) is accountable for most of the shared responsibility in the SaaS model. More specifically, the vendor holds most of the responsibility for security of the cloud (i.e., greasing the gears under the hood of their service), while the customer holds responsibility for security in the cloud (i.e., using the service in a secure way). That’s not to say that the SaaS vendor is fully responsible for everything from the hardware up to the software service they’re providing, though, since a SaaS vendor may (likely) use a separate PaaS or IaaS service as we’ve discussed to provide their own SaaS service. For example, if I want to launch a web app to provide a paid service for people, I would most likely use virtual infrastructure from Linode to run that service — I wouldn’t be responsible for the maintenance of the underlying hardware, but I would certainly be responsible as previously discussed for the secure and resilient configuration of my resources to protect myself and my customers.

From the customer perspective, SaaS tends to come with general benefits like easy access from anywhere via the internet, high reliability, payment flexibility (e.g., we all know Gmail is free), strong security, and generally the abstraction of the “how it works” away from the “what it provides”. When I’m accessing software over the web like Gmail, or Word, or OneDrive, I access it with the expectation that it’s just going to load, that it’s secure, that I’m not going to lose any data, etc., because I’ve placed trust in an established vendor’s guarantees of those things. Now, with SaaS, the software being provided as a service, while possibly somewhat customizable by end users (e.g., for changing styles and themes and certain settings based on personal preferences), is packaged in a way that intentionally confines users to using it as expected. End users are not tasked with developing SaaS services further before using them or making them more secure as services — that part is handled.

Ultimately, SaaS customers are purely responsible for the secure use of SaaS since that’s the full scope of their control. This generally includes largely data-, account-, and information-centric security responsibilities like:

Not exposing or sharing sensitive information with users who should not have access
Not sharing account credentials with other users and not reusing a password for the SaaS account that is used elsewhere
Enabling optional security features on the SaaS account like MFA; if an admin, enforcing an MFA requirement for all other organization users
Training other end users of the SaaS product in the organization on how to use it securely if applicable; for example, if a new product is being launched to deliver a service to a full organization (e.g., a new intranet or a CRM for a higher education institution)
If an admin, setting up role-based access control from the SaaS product’s administrative settings if applicable (for organizations), following the principle of least privilege
If an admin, setting up monitoring and alerting from the SaaS product’s administrative settings if applicable (for organizations)
If an admin, tracking information or identity compromises from the SaaS product’s administrative settings if applicable (for organizations)
Keeping up to date with notifications from the SaaS provider about changes to their product, especially if managing the product as an admin for an organization
Verifying that the SaaS product supports the organization or business’s security, policy, and legal requirements before purchasing if you’re part of decision-making about SaaS product purchases
Verifying that the SaaS product supports disaster recovery and general business continuity before purchasing if you’re part of decision-making SaaS product purchases

Specific security requirements around the use of a SaaS product will vary depending on the product itself but general information security best practices around things like password management, MFA usage, information protection, monitoring and alerting, access control, etc. are widely applicable to maintaining security when using this service model. To reiterate, SaaS is both simple and confining, and it’s not for developers hoping to launch their own service as is IaaS or PaaS, but rather it’s for end users with an internet connection and a specific goal met by a specific SaaS product.

Conclusion

To summarize this quite lengthy article, let’s take a look back at the cloud pyramid, but this time with an additional component. I guess technically this image is adding another thousand words but at this point who’s counting? I am. We’re at 3160 so far.

I was struggling to find articles online that really dove into the semantics behind the use of a pyramid to represent the relationship between each of these three service models. As a result, I started doing some thinking and realized that by drawing a box sitting over the pyramid, the visual can really emphasize the how the ratio of customer-to-vendor responsibility in the shared responsibility model of cloud security changes across each of these service models. We established that IaaS offers the most technical and creative freedom to customers, but IaaS customers also hold the most responsibility for security in comparison to the other two models. Of course, responsibilities held by the customer are consequently not held by the vendor. So, as you move upward through PaaS to SaaS, the scope of customer responsibilities around security (the space in the pyramid) decreases overall while that of the service provider (the space around the pyramid) increases.

Perhaps the most important note to end with is that cloud security, regardless of the service model — is never a one-sided responsibility.

The ARC Protocol — Keeping Emails Afloat on the Voyage Through Strict Security Policies

Austin Hunt — Sun, 23 Oct 2022 23:58:55 +0000

This article will first provide some context around the SPF, DKIM, and DMARC protocols for email security, and will establish the reasoning behind the announcement of a new protocol called ARC in 2016. It will then offer an overview of how the ARC protocol works in support of the other three protocols.

SPF: A Screen from the Sun of Scammers

Sender Policy Framework (SPF) is an email authentication protocol allowing domain administrators to define, with a specifically formatted DNS TXT record, an explicit list of mail servers that are authorized to send mail from their domain. This is a significantly valuable protocol because enabling it removes the ability for attackers simply spoof emails from email addresses within the domain. Or, put more strongly, not enabling for a domain (e.g., example.com) gives any interested attacker the option to spoof emails from any email address within that domain (e.g., ceo@example.com), allowing them to potentially leverage and exploit the authority of certain people (e.g., CEOs, directors, presidents, etc.) within an organization to trigger some action such as clicking a link or providing confidential information. Moreover, it’s fairly straightforward to set up, especially with tools like MX Toolbox SPF Record Generator.

Stopping the Bad Guys with DKIM Possible

Since the other protocol that DMARC builds upon is DomainKeys Identified Mail (DKIM), and DKIM is based on the idea of digital signatures for protecting and verifying message integrity, let’s quickly review how digital signatures work. In short, a message sender first hashes their message to produce a message digest, then encrypts that message using their own private key to produce their digital signature, which gets appended to the message before transmission. Upon receiving the message with the appended digital signature, the receiver hashes the received message using the same hash function as the sender, and then uses the public key of the sender to decrypt the digital signature back into a message digest. If the message digest from the digital signature decryption matches the message digest produced by hashing the received message with the same hash function, the receiver can be sure that the message came from the sender and hasn’t been tampered with during transmission.

With that in mind, DKIM works essentially the same way. The sending email server essentially takes an outbound email, hashes it (well, parts of it, e.g., the subject, the from address, the body, etc.) to produce a message digest, encrypts that digest with a private key to create a DKIM signature, then appends that signature to the outbound email before transmitting it. The receiving server, upon receiving the signed email, hashes the email with the same hash function used by the sender to produce a new message digest, then retrieves the sending server’s public key by querying DNS (since the sending server public key is stored publicly in DNS) and uses that public key to decrypt the appended DKIM signature back into a message digest. If the two digests match, the email has not been tampered with and it certainly came from the expected sender. If they don’t, well, different things can happen, which is where DMARC comes in.

DMARC: Demarcating Good Emails from Bad Emails

First published in 2012, the Domain-based Message Authentication, Reporting and Conformance (DMARC) email authentication protocol builds upon the SPF and DKIM protocols to enable email senders and receivers to cooperatively defend against and report on fraudulent emails impersonating a domain. When emails fail to authenticate against SPF or DKIM, we need an explicitly defined way of handling and reporting those failures, whether that means blocking emails entirely or simply flagging them as suspicious and sending them on their merry (or rather, maily) way. DMARC is the protocol that allows domain administrators to define this handling and reporting logic. Setting up DMARC is a matter of first choosing one of three policies: none, quarantine, or reject. The none policy is, as expected, the least restrictive policy that essentially does nothing aside from monitoring for report gathering; the quarantine policy takes the emails that fail authentication and puts them in the recipient’s junk folder rather than their main inbox; lastly, the reject policy is of course the most restrictive in that it completely blocks the delivery of emails that fail authentication. There are also a number of other configurable properties for the DMARC protocol centered on things like aggregate and forensic reporting, subdomain-specific policies, and strict versus relaxed alignment rules as seen pretty clearly in this very simple MX Toolbox DMARC Record Generator tool.

The important thing to note is that DMARC can be enabled with a range of very different behaviors for a domain depending on specific needs, from super simple, non-blocking report generation about fraudulent emails to full-fledged blocking of emails that look even slightly fraudulent — even in cases where they aren’t. This leads us to ARC.

ARC — Keeping Emails Afloat with Strict Security Settings

In defense against rising — rather, “spiking” — threats to email security, an increasing number of domains are adopting strict DMARC policies due to the protection it provides from attackers and the visibility it provides of their activity. But there is a catch. Anyone who works in software surely knows that whenever you start locking a system down to make it more secure, new usability issues are bound to pop up (e.g., locking down east-west traffic in a data center with a firewall to make a local network more secure inherently increases the difficulty of setting up new applications and services within that network).

That doesn’t make the security not worth it, though.

Assume an organization has set up the SPF and DKIM protocols and has also set up DMARC with the reject policy such that any emails failing authentication against SPF and DKIM do not get delivered. Now, also assume that the organization has a communications team that uses a mailing list, or third-party-forwarder, to send out a weekly newsletter to subscribers, or perhaps marketing materials to interested potential customers. Each week, when sending out the mass email, the communications team sends their message to the mailing list server which consumes, processes, slightly changes, and then relays the message onward to the subscribers of the list. Unfortunately, because of the changes made to the message by the mailing list during the processing, the message no longer produces the same digest when hashed, which means DKIM will fail on the receiving end. Also, if the organization hasn’t explicitly included the address of the intermediary mailing list server in the authorized senders list of their domain’s SPF record, SPF will also fail since the receiving mail server will attempt to verify the received message isn’t spoofed by asserting the sender’s address (the address of the mailing list server) is in the list of the domain’s authorized senders (where the domain is pulled from the email’s Return-Path).

In other words, if A sends to B and B forwards to C, C is going to find that B is not authorized to send on behalf of A if A hasn’t set up B as an authorized sender with SPF. Now, if the organization sending out this communication has set up their email security policies to block delivery of these messages failing authentication, they’re not reaching their audience.

As explained by Steven Jones, Executive Director of DMARC.org the Authenticated Received Chain (ARC) protocol announced in 2016 aims to fix this problem. Basically, with this protocol, the authentication results of the original email, whether pass or fail, can be preserved across an arbitrary number of hops to a final destination (no supernatural horror involved, I promise!).

Taking the previous example, the intermediary server B would observe and record the authentication results of SPF and DKIM of the email from the original server A and would append the results to the email before sending it onward to C. It appends these results in the form of a new ARC-Authentication-Results (AAR) header combining the SPF, DKIM, and DMARC results with an instance number i, where i is really a count of intermediary servers in the chain so far. It would also add an ARC-Seal (AS) header, which is a combination of a that same number i, a DKIM-esque signature of previous ARC-Seal headers, and the validity of prior ARC entries. Lastly, it would add an ARC-Message-Signature (AMS) header, which again combines the instance number i with a DKIM-esque signature of the entire email minus the ARC-Seal headers. So, as you move down a chain of intermediary forwarding services of arbitrary length, the instance number i starts at 1 at the first forwarder and continues incrementing until reaching the last forwarder, and each forwarder has to use the ARC-* headers from the previous forwarder to calculate its own new ARC-* headers. At the end of the line, the receiver obtains the preserved authentication results for the original email by 1) verifying that there are no missing ARC-Seal entries and each ARC-Seal entry states that the previous one is valid, and 2) validating the newest AMS (with the highest instance number i), which works similarly to DKIM signature verification discussed previously.

This chain means that even if SPF and DKIM fail for the email at the destination C, C can alternatively choose to validate the email by validating the ARC chain.

That is, assuming C trusts B as an ARC signer, and B signed the authentication results of the original email, then C can trust those signed original results as valid. This same idea, of course, can be arbitrarily extended to an ARC chain of any length if each successive server in the chain trusts the ARC signature of the server before it and the receiver trusts the last one.

Conclusion

With the announcement of the ARC protocol, the trend toward stronger email security via stricter DMARC policies can continue without compromise because ARC will eliminate the common problem of SPF and DKIM failure associated with intermediary email forwarding services. The ARC protocol, at a high level, functions somewhat similarly to a chain of trust used for validating SSL certificates, but it’s specifically geared toward the preservation of trusted email authentication results (from SPF, DKIM, and DMARC) through a multi-hop chain of intermediary services that an email may travel through before reaching its final recipients. As outlined here on DMARCLY in 2019, contrary to the SPF, DKIM, and DMARC protocols, enabling ARC doesn’t require any specific action or DNS updates, as the ARC implementation happens server-side, transparently to senders. Since ARC was published as RFC 8617 in July 2019, its implementation is still in early stages but will certainly speed up, and there are actually already some email services, like Sympa and Google’s Gmail (as one would expect), that are using it.

Please enjoy the following GIF of a chain made of arcs. Yes, I am assuming the edges are directed.

Breaking Down Modern Trust: Digital Signatures and Their Impact on Business

Austin Hunt — Sun, 23 Oct 2022 23:37:17 +0000

Running a successful business, whether in finance, education, health, manufacturing, retail, or even doomsday prep gear distribution (that’s real), requires trust — trust between the business and other businesses providing third party services (or investors providing money), trust between the business and their clients using their service, and trust within the business itself. Without inter-business trust, an organization cannot fully leverage the services provided by others; without client trust, the services provided by a business have no value; without intra-business trust — that is, trust among the internal units of the organization — communication channels that allow for internal productivity fail and services cannot be provided, which then can collapse both client and inter-business trust. As Bruce Nolan would say,

“That’s the way the cookie crumbles.”

Extending this idea to the modern world, in which a business’s success increasingly requires a digital presence, we can begin thinking about the value of digital signatures in bolstering the architecture of that trust triangle in a digital context.

What Do Digital Signatures Provide?

In a nutshell, digital signatures provide proof that something digitally received is coming from the expected sender and has not been tampered with during its transmission. This means that when using digital signatures, we can receive information and files over the internet without losing our trust in the integrity and authenticity of what we are receiving. On the other side of that same coin is non-repudiation, or the guarantee that the sender cannot deny their authorship of the item received since their digital signature (ultimately, their private key) is unique to them.

How Do They Work?

On the sender side, the message being sent (which could simply be text or perhaps a file) is first hashed to produce a message digest. That message digest is then encrypted using the private key (assumed to be truly private and unique to the sender). The output of that encryption, which is the digital signature, gets appended to the original message being sent. Note here that the original plaintext message is not encrypted by the creation of a digital signature, so encrypting the message is a separate optional step that can be taken pre-transmission for confidentiality purposes. More details about this step are provided in the What Digital Signatures Do Not Provide section.

Upon receiving the message, the receiver uses the public key owned by the sender to decrypt the digital signature, which produces the message digest (i.e., the hash output). Since public key infrastructure is built on the idea that something locked with a private key can only be unlocked with the corresponding public key and something unlocked with the public key must have been locked by the corresponding private key, the receiver can trust that the message digest came from the expected sender who owns the private key. Knowing the message digest, the receiver then hashes the plaintext message (possibly after decrypting it if it was encrypted pre-transmission for confidentiality) to produce their own message digest. To do this, they use the same hash function that was used by the sender. If their message digest matches the message digest produced from decrypting the digital signature, then the message is guaranteed to have come from the expected sender without tampering from a middleman. The key assumptions here are the true privacy of the sender’s private key and the use of a cryptographically secure hash function that will not produce the same message digest for two distinct messages. For example, you wouldn’t want a hash function that produces the same digest for a) a malicious message linking to a fake website and b) a real, non-malicious message with information about a policy update.

What Digital Signatures Do Not Provide

While digital signatures do guarantee the integrity of received digital content and provide non-repudiation (i.e., the author of the signed content received cannot deny their authorship as the sole owner of the private key used to generate the signature), they do not inherently guarantee confidentiality. Digital signatures do not necessitate the encryption of the message whose integrity is being validated. Rather, the message digest (the hashed value of the message) is encrypted with the private key and that encrypted value is appended to the plaintext message before transmission. To achieve confidentiality as well, the message itself would also need to be encrypted by the sender with the public key of the receiver pre-transmission and then decrypted by the receiver with their own private key. Note that these “guarantees” assume that private keys are truly kept private, which is the assumption underlying public key infrastructure as a whole.

A Real-World Example from My Own Experience

Consider a higher education institution (which, indeed, is a business) which pays for a Microsoft 365 tenant that provides all faculty, staff, and students with the Office 365 suite of tools for file sharing, emailing, chatting, and generally collaborating both within the organization and with external users, groups, and vendors. In this scenario, through the lens of the previously discussed trust triangle, we consider students (prospective and current) as customers, faculty and staff as the internal business actors, and entities like vendors and donors as external stakeholders on the inter-business edge.

The day-to-day business processes of each administrative and academic department, each office, and generally each team within the organization are critical to its overall success, and many of those processes heavily involve consistent internal sharing of (and acting upon) information in the modes of emails, forms and files representing various aspects of student (customer) statuses from academic standings to financial aid eligibilities to degree audits and so on. Thus, the trust in the integrity of digital information is critical to those various processes; a loss of trust removes “actionable” from “actionable information.” A loss of action is a loss of productivity, which crumbles the cookie.

Moreover, higher education institutions significantly depend upon external vendors for managing things like events, facilities, software, websites, IT infrastructure, and more. While the initial touchpoints with such vendors certainly require trustable communication, especially when regarding expensive services, the ongoing relationships between the organization and those parties often involves more intensive file sharing, emailing, and collaboration that requires both sides to trust in their digital exchanges. Losing faith in the integrity of files or software shared by a software vendor, for example, could have expensive negative implications resulting in the termination of a contract, and perhaps the loss of a student-facing service which affects their trust as customers.

Of course, students need to be able to trust the school they’re attending or considering attending, and a big factor in that trust is the communication they receive (or don’t receive). A majority of the communication students do receive is sent via email (though the effectiveness of this channel is questionable, but that is a rabbit hole that we can avoid here). Let’s say a student enters their contact details into a “request more information” form on the school’s public website. Then, the school adds them to a communication plan, and they begin receiving spammy or malicious-looking emails from what appears to be that school — or worse, they get a virus — because of the email content being tampered with during transmission. If a student doesn’t trust information shared by a school, the chance of that student crossing that school off their list increases; at scale, that gets expensive for the institution.

Fortunately, the Office 365 suite on which the institution’s faculty and staff rely for file and information sharing offers methods for adding digital signatures both to emails sent via Outlook (in addition to those regular signatures) and to files created with Office apps like Word and Excel. This means receivers of files and emails sent by people who use those digital signatures (this is key) can be confident in their content, whether the receiver is a faculty member, a staff member, an external party, or a student.

Unfortunately, these signatures are optional, and their additions are up to the individual authors. Currently, it doesn’t look like Microsoft tenant admins are able to establish a domain-wide policy requiring their use. Rather, an issue like this prompts a need for communication across the organization about the importance of email security and integrity that includes instructions for enabling and using digital signatures when authoring content — especially important content.

Conclusion

In short, we need trust to run successful businesses, because a loss of trust means a loss of actionable information, and a loss of actionable information is a loss of action, which means a loss of productivity. One way (of many) of supporting that foundational trust is the use of digital signatures, which use public-key cryptography to allow senders to digitally sign messages and receivers to verify the integrity and authenticity of those signed messages. Digital signatures, while indeed used to verify integrity, do not inherently protect confidentiality; messages being signed and verified are not encrypted with digital signatures by default and need to be encrypted as a separate step before transmission in order to keep them private.

Movin' On Up: An Analysis of The Privilege Escalation Vulnerability CVE-2022-26923

Austin Hunt — Sun, 23 Oct 2022 23:25:31 +0000

This article provides analysis of CVE-2022–26923, a vulnerability at the intersection of Active Directory (AD) and Active Directory Certificate Services (AD CS) that was discovered and reported privately through Zero Day Initiative by Oliver Lyak and patched on May 10, 2022, which allowed for a low-privileged attacker to escalate their privileges through impersonation of another computer account under the guise of a requested authentication certificate.
As the go-to directory service from Microsoft for Windows domain networks, Active Directory (AD), or more formally Active Directory Domain Services (AD DS), is a prime target for attackers who want to obtain access to resources on a network.

In a nutshell, AD functions as both a distributed data store and an access control mechanism for organizations using it, including within its scope not just users and groups but other objects like servers, printers, and computers within the network - i.e., networked resources to which access needs to be controlled. Offering quite a simple hierarchical organization, AD makes it easy for domain administrators (often a centralized Identity and Access Management team within the organization) to control access to resources; it also enables authorized network users to navigate and query for information about other users and networked resources in their organization.

The Challenge

Let's start with an assumption: you're a user on the network with normal, non-administrative permissions - or perhaps you're not, but you have obtained the identity of someone who is.

How can you use Active Directory, as described above, to (perhaps further) escalate your privileges and obtain access to a resource on the network to which you currently do not have access?

First, privilege escalation would be a bit difficult without visibility of whose privilege level should be targeted. Of course, as mentioned previously, AD does offer the ability for an authorized domain user to simply query the data for information they're interested in like usernames, email addresses, group memberships, etc., which is one way that visibility could be obtained. However, we've seen that with a tool like Bloodhound, that same domain user (or someone impersonating them on the network) could automatically obtain a graphical visualization (built with a fantastic graph data platform called Neo4j) not only depicting who the domain administrators are within AD, but also what the shortest path of privilege escalation is to each of those administrators - all essentially at the click of a button.

Basically, any domain user can obtain this information about their domain by logging into AD, running SharpHound to collect the data from it in JSON format, and then piping that collected data right into the Neo4j-based Bloodhound visualizer. From that point, it's a matter of following the yellow brick road - that is, mapping a route to a target with desired privileges by following the graph edges that reveal useful vulnerabilities. Graph theory, permissions, memberships, oh my.

As an example, you may want to access a domain admin's account, and you notice in the Bloodhound graph that a non-admin has permission within AD to force change one or all of the domain admins' passwords, so you identify that non-admin as the next target for impersonation.

Now, assume that you have identified a target for impersonation-based escalation of privileges. Assuming that target is a computer or server account (not a user account), CVE-2022–26923 was a vulnerability that offered a method of carrying out that impersonation.

A Pause for Some Context

Introduced in Windows Server® 2008, Active Directory Certificate Services (AD CS) is another AD Server Role leveraging public key infrastructure (PKI) to provide domain users with the ability to create digital certificates. Such digital certificates could be used for general encryption to protect data confidentiality, for the generation of digital signatures to protect message integrity during transmission, or even for authentication against AD, which is the focal use case for the purpose of this analysis since successful privilege escalation via impersonation is all about false positives when authenticating.
With public key infrastructure, on which AD CS is built, one of the overarching ideas is that with any public-private key pair, the private key is kept truly private by the owner and thus can be used to identify and authenticate that owner (which has additional non-repudiation implications). If that owner signs (encrypts) something with their private key, the only way it can be decrypted is with the corresponding public key; more importantly, any message decrypted with a public key can only have come from the owner with the corresponding private key. This theory underlying PKI opens the door to digital certificate-based authentication.

By associating, or binding, the digital certificates with accounts on a network in AD (whether computer accounts, user accounts, or device accounts), AD CS allows for those accounts to authenticate against AD using their respective digital certificates. Certificate-based authentication is itself an interesting process relying on password entry in addition to digital signature verification, but this paper will avoid diving into that rabbit hole. Note that this process of binding a digital certificate to an identity for the purpose of it being used to authenticate them should be done in a way that other identities cannot forge that binding. This was the problem behind CVE-2022–26923 - AD CS allowed digital certs to be bound to identities via an attribute (dNSHostName) that could be reused arbitrarily for other identities.

Using CVE-2022–26923 to Escalate Privileges

As documented by the Semperis Research Team in August of 2022, there were ultimately two main steps that needed to be completed in order to exploit the CVE-2022–26923 privilege escalation vulnerability. First, the attacker needed to change the dNSHostName of their own computer account to match the target computer or server account's dNSHostName value (e.g., that of a domain controller computer account). Then, the attacker needed to obtain a digital certificate bound to their own falsely identified computer account by requesting one with a template configured with the SubjectAltRequireDns flag. This flag essentially sets the Subject of the digital certificate to the dNSHostName value of the requesting computer account (without any sort of validation), where the Subject ultimately identifies the computer account bound to the public key. Note that for the first step, there was actually a prerequisite of the attacker creating their own computer account as a logged in user in AD (a feature enabled by default in AD), since dNSHostName attributes can be modified only on computer accounts created by the editor.
The presence of this vulnerability meant that an attacker with access to AD could pick and choose from active AD computer accounts and use a default, built-in component of AD to arbitrarily impersonate any desired target via false digital certificate authentication.

Mitigation

The easiest, most sledgehammery (looky there, I coined a term) fix for this problem would probably be to simply not run AD CS within a Windows domain network, as AD CS is the root of the CVE-2022–26923 rot. This would entirely prevent digital certificate-based authentication, but of course flipping such a broad switch has equivalently broad implications at the enterprise scale which may include, for example, service outages for services running on machines that use certificate-based authentication against AD for valid purposes.

Luckily, Microsoft made an announcement pretty quickly in response to the vulnerability disclosure about a new change to the way certificate-based authentication would be handled by Windows domain controllers. The announcement included explicit actions that needed to be taken to protect domain environments, namely the application of the May 10, 2022 update which placed AD devices into compatibility mode designed primarily to generate audits ahead of a recommended switch to full enforcement mode which, in short, would begin blocking certain authentication attempts not meeting updated digital certificate criteria.
Those criteria were centered on the idea of certificate mappings, or the bindings mentioned previously, where a mapping between a digital certificate and an account is considered weak, or insecure, if it relies on an identifier that can be reused by other accounts (i.e., the dNSHostName attribute). Certificates weakly mapped to identities would consequently generate audit events in compatibility mode for investigation and fixing, and would entirely fail to authenticate those identities upon the enabling of the update's full enforcement mode.

Conclusion

In short, CVE-2022–26923 was a significant vulnerability within the Active Directory Certificate Services server role that allowed attackers to leverage weak bindings between identities and their digital certificates such that one could completely bypass the security of public-key infrastructure by simply requesting (and obtaining) a digital certificate identifying them in AD as their desired target. Upon its discovery and disclosure on May 10, 2022, it was quickly addressed by an update to the AD CS server role which requires stronger, non-forgeable bindings between digital certificates and AD identities.

Foundations: First Blog Post

Austin Hunt — Sat, 05 Mar 2022 18:30:44 +0000

As I sit here preparing to write before these two Chrome windows -- one presenting a blank canvas and the other claiming to present Expert Advice on how to fill it -- I can't help but to think of that episode of SpongeBob SquarePants in which he pours his heart and spongey soul into the first word of that 800 word essay for Boating School in a subconscious attempt to escape the work of actual writing.

The. I feel you, SpongeBob.

Luckily, I don't have a blog post due first thing in the morning -- nor am I attending Boating School -- so I'm not technically procrastinating, but one could argue this cartoon-themed introduction on what's supposed to be a developer-themed blog post is just as much a useless decoration as SpongeBob's highly intricate calligraphy.

One would be wrong. The theme of this post is just that:

I don't know what I'm writing about yet.

I could say that I started writing this post with a clear direction in mind -- that I'm taking you, the reader, on a journey into the great beyond, like I'm some sort of confident safari tour guide with one of those nice pairs of binoculars that he doesn't even use because he sees that far ahead. I could recommend that you leave your mental umbrella behind because there's nothing but clarity ahead, and that there's no need to use Waze because I've been memorizing the map to where we're going and studying traffic patterns since I was three years old. I could promise that I won't use any more ridiculous analogies.

As much as I'd like those things to be true, they're not. I honestly don't even know what the next post is going to be about. It could be about puppies, and how they're all ultimately good (it's been formally verified with a symbolic model checker). Or, it could be about my experience with the automation of enterprise-level web application deployment. Either way, I'm pretty stoked. I've never really maintained my own official blog on a platform like this with the expectation that other people will be reading what I'm writing, but I've reached a point in my career where I'd like to start prioritizing engagement with the developer community for a couple of reasons. First, I feel like I've collected a decent amount of development experience in the forms of challenges, successes, and failures worth sharing with others. Secondly, and more importantly, there is a ton to be learned from other developers. The ever-changing nature of tech guarantees that we're only ever scratching the surface, and the set of learnable things, like $R\mathbb{R}$ , is uncountably infinite.

What To Expect From My Blog

While I don't know exactly what I'm aiming for yet, there are a number of topics that I'm considering for upcoming posts:

Django development tips and tricks - for context, I started web development with Django in 2017 at College of Charleston under guidance from Dr. Ayman Hajja, an absolute Django expert (who also happens to be a source of inspiration for starting this blog)
Building custom automation frameworks in Python
Setting up custom CI/CD pipelines using GitHub Actions, Docker, and adnanh's webhook project
Using Ansible for automating infrastructure management
Using Icinga 2 with Icinga Director for network monitoring and alerting
other niche "how-tos"
the work/life line and the challenge of defining that as either border:20px solid black; or border:none;
projects for school that I'm working on or excited about
the intersection of being both a fully remote student and a fully remote IT employee
maintaining interest in hobbies outside of software and web development, and allocating time to those things (with focus on avoiding or dealing with burnout from work/school)

First Post Feedback

I want to thank you for reading this far, even if you're a spider automatically crawling this text -- there'd be no web without you, you creepy crawler, and I've grown to love the web. For you non-arachnids still reading, leave a comment on this post if you liked it, or even if you didn't like it, and let's connect! If there's anything I've mentioned in this first post that sounds interesting, or if there's something I didn't mention that you'd like me to consider as a topic for a future post, let me know!