After the Click: The Inner Workings of Application Access

From social media and cloud-based services to anything and everything requiring an app, we spend a lot of time logging into applications. Have you ever stopped to wonder what happens after you click that login button? The inner workings of application access involve a complex interplay of authentication, authorization, APIs (application programming interfaces), security measures, and network conditions. Let’s take a closer look at what happens behind the scenes after the click.

The Initial Handshake – Understanding Authentication

The journey into an application begins with a crucial step known as authentication. This process is fundamentally about ensuring you are who you claim to be. A variety of methods can be employed for this purpose, each offering various levels of security and user convenience. Passwords, though widely used, represent just the tip of the iceberg. In recent years, more secure and sophisticated options like biometric verification — think fingerprint or facial recognition — have gained popularity. As it has become evident that passwords are not particularly secure, extra measures like multi-factor authentication and certificate-based authentication have become commonplace.  A digital handshake occurs between the user and the application upon successful authentication, establishing a trust relationship. This moment is critical; its where digital doors open, allowing access into the application’s ecosystem. However, it’s important to understand that this step doesn’t determine what you can do or see within the app. That’s governed by a subsequent process known as authorization.

Authorization and Access Control

Following successful authentication, the user’s journey within an application transitions to a critical phase known as authorization. This stage is instrumental in defining the scope of the user’s privileges and interactions within the app. Unlike authentication, which verifies identity, authorization delves into the specifics of what authenticated users are permitted to do. For instance, in a corporate setting, all employees can log onto the network, but only certain employees can see data specific to HR or Finance. This is known as role-based access control, a key part of zero trust where each employee has access only to what they need to do their job in order to defend against both external threats and potential internal misuse. This not only enhances the security posture of the application but also tailors the user experience by filtering accessible content and functionalities to meet the user’s needs and privileges. In essence, authorization acts as a sophisticated filter, carefully curating the user’s access to ensure it aligns with their rights and the organization’s policies, thereby maintaining the integrity and confidentiality of the application’s resources.

The Role of APIs in Application Access

APIs, or Application Programming Interfaces, are the unsung heroes of digital connectivity, seamlessly bridging the gap between disparate software systems. They serve as the essential conduits for data exchange, enabling your device to communicate with an application’s backend servers. Think of APIs as the linguistic experts of the digital world, translating requests and responses between your device and the app in a language they both can understand. This linguistic dexterity allows for the dynamic delivery of content and functionality, making your interactions with the app smooth and efficient.  In the context of application access, APIs are critical for executing a myriad of tasks behind the scenes. From the moment you authenticate, APIs are at work, fetching your profile information and preferences and customizing your in-app experience based on your permissions. They facilitate real-time data synchronization, ensuring the information you see is current and accurate. Additionally, APIs enable third-party integrations, allowing apps to offer enhanced features and capabilities by leveraging external services and data.  Moreover, APIs are pivotal in maintaining the security of the application access process. They enforce strict data access protocols, ensuring that only authenticated and authorized requests are processed. This layer of security is crucial in protecting sensitive user information and preventing unauthorized access to the application.

Ensuring Security Throughout the Access Process

When it comes to application access, safeguarding against threats and vulnerabilities is a top priority for developers and IT professionals alike. Integral to maintaining this security are state-of-the-art encryption methods, which play a crucial role in protecting data as it travels across the internet. Encryption ensures that even if data is intercepted, it remains indecipherable to unauthorized parties.   To further bolster security, conditional access products are implemented to enforce security policies that prevent potentially compromised devices from gaining access. These systems are vital in identifying potential threats, allowing immediate action to mitigate risks.  Equally important is the process of rolling out timely updates and patches. This not only addresses known security flaws but also adapts to the continually evolving landscape of cyber threats. By staying ahead with these updates, applications can shield themselves against the latest exploits and attack vectors.  Together, these multifaceted security measures form a comprehensive approach to protecting the integrity of application access. Through diligent implementation and ongoing vigilance, developers and security teams work hand in hand to create a secure environment for users to connect and interact with applications.

The Impact of Network Conditions on Application Access

The quality of network connectivity is pivotal in determining the efficacy of accessing applications. Variabilities such as bandwidth availability, latency levels, and overall network congestion can significantly influence the ease with which users can connect to and interact with apps. Poor network connections can lead to frustrations like slow loading times, interrupted sessions, or even the inability to access certain functionalities within the application.  To address these challenges, developers implement various strategies aimed at optimizing the user experience under diverse network conditions. Techniques such as load balancing are utilized to distribute incoming application traffic across multiple servers, thereby preventing any single server from becoming a bottleneck. Content caching is another critical strategy, where frequently accessed data is temporarily stored closer to the user, reducing the need to fetch data from the application’s primary servers and thus speeding up access times. Additionally, network optimization efforts focus on streamlining data transmission paths and protocols to ensure efficient data flow even in less-than-ideal network environments.  These efforts are essential in ensuring that application access remains robust and user-centric, minimizing the impact of fluctuating network conditions on the overall digital experience. By proactively addressing these challenges, developers can ensure that applications remain accessible and performant, regardless of the underlying network state.

The Future of Application Access – Trends and Innovations

The trajectory of application access is being significantly influenced by emerging trends and technological breakthroughs. Among the most noteworthy is the shift towards Zero Trust security models, which assume no entity is trustworthy by default, whether inside or outside the network, dramatically altering traditional access paradigms. A key part of Zero Trust is the push towards passwordless authentication, which provides security beyond the simple password and even beyond multi-factor authentication methods which are increasingly falling prey to sophisticated hacks (and less sophisticated but no less effective social engineering techniques.)  Artificial intelligence and machine learning are playing increasingly crucial roles, enabling more personalized and adaptive access experiences. These technologies enhance security and make application access more intuitive and responsive to user behavior and environmental contexts.  As these trends converge, they herald a new era of application access, characterized by heightened security, improved efficiency, and a more seamless user experience. The ongoing innovations in this space promise to redefine our digital interactions, making the way we connect to applications more secure, efficient, and tailored to individual needs.

Understanding the Cisco Duo MFA Breach

On April 1, 2024, a significant security breach was reported by Cisco, impacting its Duo multi-factor authentication (MFA) service. The Cisco Duo MFA breach occurred through a third-party telephony provider that manages SMS and VOIP services for Cisco Duo. A successful phishing attack enabled hackers to obtain employee credentials at the telephony provider, which were then used to access systems and download MFA SMS message logs. These logs contained metadata such as phone numbers, carriers, and geographical locations, though it’s crucial to note that the content of the messages was not accessed​​.

The Scope and Response

The Cisco Duo MFA breach specifically involved the logs of messages sent between March 1, 2024, and March 31, 2024. While the actual content of the MFA messages was secure, the metadata contained within could potentially be exploited for further targeted phishing campaigns or to facilitate other forms of social engineering attacks​​.

Upon discovering the breach, the affected telephony provider took prompt measures to contain the incident. This included invalidating the compromised credentials and enhancing security protocols to prevent future breaches. Cisco has been transparent with its customers, advising them to be vigilant and to educate their users on the risks associated with social engineering​.

Common Vulnerabilities in MFA Systems

While MFA is a robust security measure, the Cisco Duo incident highlights some vulnerabilities inherent in MFA systems, particularly those relying on telecommunication-based methods such as SMS and VOIP:

1. Phishing Attacks: As seen in the Cisco Duo breach, phishing remains a significant threat. Attackers can use sophisticated tactics to trick individuals into providing access credentials.
2. Social Engineering: Access to metadata from MFA systems can aid attackers in crafting more credible phishing attempts and other social engineering strategies.
3. MFA Fatigue: Attackers may repeatedly request MFA codes to wear down a user’s resistance, eventually leading them to share a code inadvertently.
4. SIM Swapping: This involves an attacker convincing a mobile provider to switch a victim’s phone number to a SIM card they control, intercepting MFA codes sent via SMS.
5. Technical Flaws and Exploits: Vulnerabilities in the software or hardware used for MFA can allow attackers to bypass security measures. For example, exploiting network-level vulnerabilities to intercept or redirect MFA messages.

Enhancing MFA Security

To mitigate these vulnerabilities, organizations can adopt several strategies:

• Layered Security: Combine MFA with other security measures like digital certificates, hardware security keys, or behavioral analytics to reduce reliance on any single security mechanism.
• Educating Users: Regular training sessions can help users recognize phishing attempts and other forms of social engineering.
• Using More Secure MFA Methods: Prefer push notifications or use hardware tokens instead of SMS-based MFA, which are less susceptible to interception.
• Regular Audits and Updates: Keeping security systems updated and conducting regular security audits to identify and mitigate potential vulnerabilities.

The Cisco Duo MFA breach serves as a potent reminder of the ever-evolving landscape of cybersecurity threats. While MFA adds a critical layer of security, it is not infallible. Organizations must continuously evaluate their security practices and educate their users to safeguard against sophisticated cyber threats.

How Linux (Almost) Had a Terrible, Horrible, No Good, Very Bad Day

If there’s one thing you can say about the people behind the xz supply chain hack, they were certainly willing to play a long con.    For the last two years, a (probable) state-sponsored hacker quietly began integrating themselves into the open source community, particularly with the people responsible for maintaining xz utils (more on what this is and what it does in a minute.)  They began systematically inserting a back door into this core component of the Linux operating system that would have allowed attackers to bypass SSH authentication and remotely access millions of systems.  We were just days away from the biggest supply chain attack in history when they were caught.

What is XZ Utils?

Xz Utils is a program that handles file compression, and it is included as part of several popular Linux distros like Fedora, Debian, and Ubuntu.  There is even a Windows version, although Windows software is usually a zip file rather than an xz file.    Programs like this are crucial because large downloads like software packages need to be compressed, or they would take forever to download even with the highest internet speed.

Open Source, Open to All

To understand how we came so close to disaster, you first have to understand how open source software works.  Open source means that the source code – the building blocks of the software – is available for anyone to see and modify.   Open source software is like buying a box of legos – sure, you can make the robot on the outside of the box, but you can also modify and invent whatever you want.  The same applies to open source software – if you have the requisite programming knowledge, you can contribute bug fixes, work on features, and shape the future of the programs you use every day.  Software like Microsoft Windows and macOS are closed source (although macOS runs on FreeBSD, which is open source, but the user interface and applications are closed source.) With these operating systems, you’re at the mercy of Microsoft and Apple to fix bugs, and as we all know, they often don’t (just take a look at this 40+-year-old bug someone found in Windows in 2018!)  The huge advantage of using an open source OS like Linux is that if you have a bug or a feature request that you want to be implemented, you can just do it yourself.    Of course, just because anyone can technically contribute, does not mean there is just software anarchy.  According to The Linux Foundation, most projects have a structure:

• Leaders

• Someone responsible for making the final decisions about features, releases, and other priorities

• Maintainers

• These people are leaders for specific areas or features; for instance, there is a documentation leader, a leader for developing device drivers, USB, etc. etc.  They are responsible for reviewing code from others before it gets added to their individual area.

• Committers

• Trusted developers who have done enough work for the project that they can make direct code changes rather than be subject to reviews by the maintainers.

• Contributors

• Anyone who contributes, be it code, documentation, or what have you.  Their contributions are reviewed by the maintainer(s) before they’re added to the project.

Foxes in the Hen House

In 2021, someone with the user name JiaT75 opened a GitHub account and made their first commit to an open source project.  They claimed it was just adding clearer error text when an untaring (aka uncompressing) process failed; at the time, it was added without comment, but in retrospect, it appears suspicious.  These changes have since been reverted. In April of 2022, Jia Tan (aka JiaT75) submitted a patch to Xz via the mailing list.  Around the same time, two people began badgering the maintainer of Xz to add another maintainer because patches were not happening fast or often enough.  Neither of these people had any history in the open source community, and after these messages they were never seen again.  Over the course of 2022, JiaT75 becomes the second most active contributor to the xz project.  In January of 2023 JiaT75 merges their first direct code change, which means they have now achieved a level of trust that allows them to implement the code for the back door.  Over the course of 2023, changes were regularly made as JiaT75 implemented the back door one piece at a time.  In February of 2024, the last few files were completed.     While this was happening, the hacker was contacting the leads of all the major Linux distributions to get them to install the updated version of xz utils.  Richard WM Jones from Redhat wrote about his contact with the hacker and Redhat’s scramble to remove the backdoor once they found it, and Ubuntu has also made public the post from Jia Tan asking them to include it.  This is an overview of the timeline, you can find an excellent detailed version with links to the GitHub submissions and e-mails here.    An Unlikely Discovery  With all the careful measures taken to make this look legit, how did they get caught?  Purely by a stroke of luck. Andres Freund, a developer working at Microsoft, was troubleshooting a performance issue on a Debian Linux system.  When you remember that no stable version of Debian was released with the vulnerability, and therefore he was working on an experimental version, the sheer luck behind this discovery is astounding.  He noticed that SSH logins were using too much CPU and recalled an error he had seen in Valgrind (a program used to monitor computer memory), so he put the pieces together.  Thanks to his keen eye and serious investigative skills, he traced the problem to xz utils and sent a missive to the Open Source Security List to describe the problem.    Most people never dig this deep into performance issues, and even if they do, it takes a lot of system knowledge to be able to trace them to the specific cause the way Freund did.

We’re Safe Now, Right?…..Right?

Supply chain attacks are obviously not limited to open source software. After all, the reason most people know the term “Supply chain attack” is because of SolarWinds in 2020, which was most certainly not open source.  But still, this shows that open source software may be more vulnerable than others.  When the fake accounts began badgering Lasse Collin about lack of updates,  his response showed that the open source developers are subject to limited time, burnout, and other struggles just like closed source developers, and adding this on top of the fact that open source development is not paid, well…it’s easy to see how someone could make themselves popular very quickly, and how maybe new code is not always tested as thoroughly as it should be.  Again, this definitely isn’t a problem specific to open source, but it’s perhaps easier to exploit.  Regardless of the development method, we need to ramp up supply chain security across the board before the next attack is successful.