The Gartner MQ for Application Security Testing Is Losing Relevance

The 2023 edition of the Gartner Magic Quadrant (MQ) for Application Security Testing is out! But is anyone paying attention anymore? Many vendors now have a portfolio of SAST, SCA, and DAST tools, and they all check for vulnerabilities. That's important, but would all of those tests prevented the SolarWinds or the 3CX supply chain attacks where thousands of organizations were affected in each incident?

The answer is no.

Russian, North Korean, and other advanced threat actors are surgically targeting software suppliers and they aren't necessarily exploiting known vulnerabilities (CVEs) or vulns in custom code that AST tools are designed to find.

AST tools are on the verge of becoming a commodity anyway. Testing for vulnerabilities still must be done of course. What's missing is the ability to detect advanced attacks on software supply chains.

I recently joined ReversingLabs. We have technology to detect malicious software and prevent it from being released like happened at SolarWinds and 3CX. Not many people have heard of ReversingLabs, but it's not a startup. They've been around for almost 15 years, but just recently started applying their core technology of malware detection to the software supply chain.

Software publishers and software consumers alike can benefit from ReversingLabs' tools. Our binary analysis will decompose ("unpack") hundreds of different types of files. No source code is required. It will find known malware and secrets embedded in the software, but even more importantly can detect novel attacks by analyzing subtle changes in behaviors or altered digital signatures.

Don't stop testing for vulnerabilities, but also realize you probably have gaps similar to SolarWinds and 3CX. I outlined some of the reasons these gaps exist in my post Software Supply Chains and Security Challenges.

Let's also see if Gartner considers expanding the Application Security Testing MQ to be the Software Supply Chain Security MQ. The current report focuses on vulnerabilities only, and it's proving to be insufficient.

Encryption, Encoding, and Hashes, Oh My!

Maybe it's because many people have entered the cybersecurity field in the past few years, but I've been seeing basic security terms used incorrectly lately. As security professionals, we need to have a good handle on the fundamentals to communicate clearly and build trust. Some terms can be confusing at first blush. With this post I'll explain, at a high level, a few basic terms like encryption, encoding, and hashing that often get mixed up.

But first, let's talk about the CIA. No, not the Central Intelligence Agency. The CIA I'm referring to is Confidentiality, Integrity, and Availability, also known as the CIA triad. The CIA triad was pounded into my brain when I first got into application security and has stuck with me ever since. It is a fundamental concept everyone in cybersecurity should understand. When a vulnerability is exploited or a cyberattack is successful, it will negatively impact one or more of these areas.

• Confidentiality means preventing data from being accessed or viewed unless it is properly authorized.
• Integrity means protecting data against unauthorized changes. Without integrity, data is untrustworthy.
• Availability means access to data and systems is maintained. A denial-of-service (DOS) attack aims to prevent or reduce availability.

Now let's dive into encryption, encoding, and hashing.

Encryption is typically used to protect confidentiality of data and often the integrity of data as well. Encrypted data is also known as ciphertext and it looks like gibberish to the human eye. The one thing that should always jump out to you when you hear the word "encryption" or "encrypted data" is that the data can be decrypted. Decrypting data means you're reversing the encryption. Decrypted data is also called plaintext or cleartext.

Data becomes encrypted by running it through an encryption algorithm using a key. A key can be a random string of bytes or a password of a certain length. There are two main encryption types - symmetric and asymmetric. The main point to take away is that symmetric encryption uses the same encryption key for encrypting and decrypting data while asymmetric encryption uses a pair of keys, a public one and a private one. With asymmetric encryption, the public key is used to encrypt data and the private key used to decrypt the data. If you see the term "public-key cryptography" or "public key infrastructure", it means that asymmetric encryption is involved.

Some common symmetric algorithms include:

• AES
• 3DES
• Blowfish

Some common asymmetric algorithms include:

• RSA
• ECC
• PGP

Encoding involves running some data through an algorithm of some sort. Encoded data is not secure and should never be called encrypted data (even though it often looks like gibberish to humans). It offers no protection when it comes to the confidentiality, integrity, or availability of data.

There are many different types of encoding, such as:

• Base64 encoding
• HTML encoding
• URL encoding

Encoding does have valid and useful purposes. HTML and URL encoding are indispensable when it comes to web browsers and web applications. Base64-encoded data is represented with standard ASCII characters, so it's perfect for sending images or other binary data over a text-based system like email.

Here's a Base64-encoded string as a example: 

    QXBwU2VjIGlzIGZ1biE=

Keep in mind that if you see an equals sign (or two) at the end of a string, that's a strong indicator that the data is Base64 encoded.

Hashing means that data is sent through a one-way, irreversible algorithm. It becomes gibberish and unreadable to the human eye. No one should ever talk about "reversing" or "decrypting" a hash value. It can't be done. There is no encryption key. You can, however, try to crack a hashed value (a hashed value is often just called a "hash"). Cracking essentially involves a big table of lookups and there are many cracking tools available to help with such things.

Common hashing algorithms include:

• MD5 (old and not secure)
• SHA-1 (also not considered secure anymore)
• SHA-2 (includes SHA-256 and SHA-512 among others)
• Argon2 (considered best for protecting stored passwords)

Finally, if you ever need to hash some data or want to encode or decode some data, take a look at this nice online utility. Use it to decode the example Base64-encoded string above!

I hope this article has been helpful to explain one tiny part of the cybersecurity ecosystem.

(This post first published as a LinkedIn article)

Software Supply Chains and Security Challenges

 

Recently I took part in a panel discussion and the topic was securing the software supply chain. It's a hot topic in cybersecurity right now. To prepare for the panel, I decided to look at changes in software development practices over the last decade and how supply chain risks have emerged because of those changes.

Four areas of change came to mind.

1. Digital transformation

A remarkable increase in the pervasiveness of software has occurred.  It was 11 years ago that Marc Andreessen said that software is eating the world.  It's even more true now. Every company is now a software company.  Recently, my wife and I wanted to see the new Top Gun movie. We used Cinemark's mobile app to review showtimes, reserve our preferred seats, pay for the tickets, and scan a QR code upon arrival.  Before digital transformation, Cinemark just showed pictures on a screen and sold popcorn.  

2. Faster time to market

Businesses today need software and applications developed and released quickly to stay relevant and gain a competitive advantage. The need to move faster drove innovation in software development. New practices, technologies, and toolsets came onto the scene including:

• Agile development methodologiesDevOps processes
• Cloud, containers, and IaC
• CI/CD tools to automate builds & deployments
• Microservice architectures

These innovations improved time-to-market, but have also introduced complexity and new attack vectors.

3. The rise of open source software

According to Veracode's State of Software Security (SOSS) report, open source code makes up a large part of an application's codebase.  It's up around 95% for a Java-based application. This led Chris Wysopal, Veracode's CTO and co-founder, to state:

    "In many respects, development teams have shifted from writing software to assembling software."

It is the job of a package manager (e.g., Maven for Java, NuGet for .NET, npm for Node.js) to perform the nitty-gritty details of assembling software, and this includes the complex process of managing direct and transitive dependencies. Package managers generally pull from centralized, public registries where thousands of open source components are hosted and shared. This opened up novel attack vectors, like dependency confusion.

 4. Shift to microservices & APIs

The move away from large, monolithic codebases has accelerated in the last 3-4 years. With microservices, software is broken into smaller, independent parts with communication happening via APIs. This allows for more scalability, flexibility, and resilience. Your organization likely consumes the APIs of service providers and other vendors. As such, they are part of your software supply chain. Poor API security is estimated to cost businesses $75 billion annually. In fact OWASP in 2019 by published a Top 10 list dedicated to API security.

Considering these dramatic changes over the last decade or so, it becomes more clear why supply chain attacks are in the news. The bad guys are still scanning systems for open ports and probing web applications for vulnerabilities. Now they are also looking to compromise CI/CD environments, insert malicious code into open source packages, steal cloud provider access keys, hack into APIs, and exploit known vulnerabilities in 3rd-party libraries. They look for weaknesses in your software suppliers too. Any software your company develops, consumes, invokes, or leverages in any way is fair game in the mind of cyberattackers.

 

Let's look briefly at two very different software supply chain incidents.

SolarWinds 

SolarWinds is a provider of IT management & monitoring software called Orion. A sophisticated and carefully-planned attack was executed in 2020 where the automated update process for Orion was compromised. Customers who updated their Orion software inadvertently gave the attackers backdoor/shell access to their environment. Up to 18,000 organizations were victimized. SolarWinds said their "software build system" was hacked to insert malicious code.

Log4Shell

Log4Shell is a vulnerability in a Java open source library called "log4j" that was discovered in December 2021. It's been called the single, most critical vulnerability of all time. Not only is it extremely severe (CVSS score of 10.0), it's easily exploitable and very widespread. It was found that 93% of cloud enterprise environments were vulnerable. The vulnerability sat unnoticed in the log4j library since 2013. Organizations around the world were thrown into panic mode scrambling to find where the vulnerable library was being used and quickly patch.

These two incidents are radically different in nature, but both have their roots in the software supply chain. The SolarWinds attackers targeted software supplied to thousands of organizations. It appears they infiltrated the supplier's CI/CD toolset to insert their own scripts and take advantage of automated DevOps processes. On the other hand, Log4Shell was not a sophisticated nation-state hack, but vast numbers of organizations were impacted because of a reliance on open source software.

There is no one solution or tool to secure the entire software supply chain. There are some "no-brainers" available today to help, like scanning your applications to identify vulnerable open source components. I recommend Veracode's Software Composition Analysis for this. Auditing your CI/CD build systems for access control and integrity is another good step to take. Software bill of materials (SBOMs) is an initiative gaining momentum as well. It will be interesting to see how this area of cybersecurity evolves in the next few years.

(This post first published as a LinkedIn article) 

Do You Code? Security Chops Will Boost Your Career

 

As a web application developer 20 years ago, I knew almost nothing about security. I remember building what seemed like a great feature that turned out to be an excellent example of How-to-Enable-a-Successful-Phishing-Attack. I was coding a Java servlet to take HTTP requests from browsers and process them. Wouldn't it be cool, I thought, if the servlet allowed for redirection to another page or another website if a special URL parameter was present? That could come in really handy!

Only later did I realize that I'd coded an open redirect vulnerability. This "feature" actually made it into production, but fortunately the special parameter name was undocumented and not easily guessable. A static analysis of the codebase would have easily found on this flaw, but no such tools existed back then.

Fast foward 20 years and employers now expect their developers to understand how to code securely. There have been too many successful hacks and appalling data breaches due to vulnerable code and poorly designed software. It's finally understood that developers play a key role when it comes to cybersecurity.

For this reason, having security chops as a developer will enhance your career. A recent study by Burning Glass Technologies found that Application Development Security will be the fastest growing cybersecurity skill from 2021 to 2025. The same study reported that on average you'll get a $12,266 salary boost by possessing that skillset.

Besides the potential for a boost in salary, there's no better feeling than writing elegant code as a developer. But what if your code allows for SQL injection? That's not elegant. Elegant code works perfectly to accomplish some task, performs well, and stands up to cyber-attacks.

To put it another way, successful software is like a 3-legged stool where the legs are functionality, performance, and security. Take away any one leg and it will fall over. 

Stepping back for a minute, let's discuss why developers historically haven't been interested in security. One of the primary reasons is they simply weren't incentivized to pay attention to it. Their performance was judged based on delivering working software on time. Security wasn't a consideration. Additionally, Computer Science programs at colleges and universities typically haven't taught secure coding. A few electives covering high-level concepts like privacy or cryptography might be available, but usually nothing practical for the real world like using parameterized queries to prevent SQL injection or properly encoding untrusted data to avoid cross-site scripting.

So as a developer, how do you acquire security skills? 

There are many ways to learn. The OWASP Top 10 is a good place to start. It explains the common types of application vulnerabilities, why they occur, and how they are exploited by adversaries. The Udemy course An Introduction to OWASP Top 10 Vulnerabilities is another good resource.

See if your employer offers interactive secure code training. One such offering is Veracode Security Labs, which allows you to try exploits on real apps, fix the code to squash the vulnerabilities, and earn certificates to showcase your secure coding knowledge. If your employer doesn't have Security Labs, you can still use the community edition or register for a free trial of the full version.

Check if your employer has a Security Champions program that you can join. As a security champion, you'll be a voice for security within the development organization and your security skills will expand while being more visible at the same time.

Here are some other resources to consider:

• OWASP Juice Shop - an insecure but realistic web app with hacking challenges
• SAFECode's Fundamental Practices for Secure Software Development - documents a foundational set of secure development practices
• OWASP's Top 10 Proactive Controls - explains practical techniques and principles to build secure applications that defend against attacks

Good luck in your secure coding adventures and a more lucrative career!

(This post first published as a LinkedIn article)

Burgers and Application Security

I love burgers. I also live in the Dallas-Fort Worth area, so was intrigued by an article in D Magazine a few years ago that caught my eye called Why Dallas is the Burger Capital of the World. What? How did I not know this?!?

And so began The Great DFW Burger Quest!

It's my tour of burger joints in the DFW Metroplex. It's a multi-year project. The pandemic set me back a little, but I'm up to 75 burger joints visited so far. Many more are on my "to do" list. I track everything on Yelp.

What does this have to do with application security? Well, there are some parallels I'd like to point out.

Building an application security program is a multi-year commitment. When an organization first dips their toe into application security, they might start with something easy like dynamic scanning of their Internet-facing web apps. It's a fine place to start, but a lot more is needed to understand your application security posture more broadly. Static analysis, software composition analysis (SCA), and manual assessments all have a place when it comes to identifying application security flaws. Implementing multiple testing techniques and automating them early in the software development process across an entire enterprise, with minimal disruption, takes both time and commitment.

At first, I assumed only burger joints would be part of The Great DFW Burger Quest. But it turns out that some of the highest rated burgers in DFW are served at local bars or family restaurants. I had to expand my quest to include these. Likewise, to mature your appsec program it would need to expand to cover not just Internet-facing web apps, but also APIs, internal applications, mobile apps, and other software that could bring risk. Secure code training for developers (or what I call The Ultimate in Shift Left) should be part of a mature appsec program as well. Instead of Yelp, you could track the growth of your program using a model such as the excellent Software Assurance Maturity Model from OWASP.

My burger quest often needs to be adjusted based on the current environment in the area. Many restaurants closed permanently due to the pandemic, including some I had planned to visit. However, I'm seeing new burger joints popping up rapidly this year. An application security program will need adjustment too. For example, recently Log4Shell, Spring4Shell, and the U.S. Cybersecurity Executive Order have highlighted a greater need for SCA, which helps uncover risks due to 3rd-party components. Organizational changes, such as a new CISO coming in, might also force adjustments to your program.

My initial burger outings were a solo activity, but now I usually have some friends join me. In the same way, a successful application security program is not a solo activity. It requires not only testing technology but also people and processes. In particular, Security and Development should be working together to build security into DevOps processes.

(This post first published as a LinkedIn article)

Airport Kiosk Admin Access

Don't underestimate the threat of shoulder surfing, especially when you're an airline employee accessing the administrative panel on kiosks at the airport.

This thought ran through my mind recently when I witnessed an employee - in a very busy ticketing area - casually double-tapping a certain spot on a kiosk's touchscreen.  A keyboard opened asking for input of a password.  Curiosity led to me continue watching as he proceeded to enter the password and access the local administrative menu.  I quickly jotted a note of what I saw for possible future testing.

One night a few weeks later, I was at the airport and found nobody in the ticketing area.  A good time for my test...

***** ACCESS GRANTED *****

Years ago I developed kiosk applications for colleges & universities as well as for Sprint retail stores. It's common practice to code in a "hot spot" somewhere on the screen to bring up a keyboard allowing for input of a password to access the admin menu (more examples here and here).  It might require a double-tap or triple-tap in a single spot, or a combination of taps in different spots.  The admin password itself is often something simple, such as the name of the business, the street number of the building, or the store number (if a retail store).

Moral of the story for kiosk admins: Be aware of shoulder surfing!

CWE: Disrespectful to Session ID in URL

Mitre's Common Weakness Enumeration (CWE) is the most comprehensive and granular taxonomy for web application security vulnerabilities and weaknesses.  So why, may I ask, is there no CWE ID for Session ID Exposed in URL?

Am I missing something?

Sure, we have CWE-384 (Session Fixation), but that's not the issue.  Session fixation in my experience is much more rare (and dangerous) compared to a session ID exposed in a URL.

Some might suggest CWE-287 (Improper Authentication) is the best fit.  That's a tough sell.  I don't buy it.

The closest one in my opinion must be CWE-598 (Information Exposure Through Query Strings in GET Request).  It's not a perfect fit, but the consequences section does refer to "impersonating a legitimate user".  That's a true risk for sure.

At this stage of the game, we probably won't see a CWE ID specific to Session ID Exposed in URL.  It seems like a no-brainer, but oh well. 

What the Tech behind this Website? Wappalyzer Knows

Trying to figure out what technologies/frameworks a web app is built upon is an important part of application security, especially pen testing.  It's something that should be done in the reconnaissance phase of an assessment.  Knowing what an application is using under the covers is a definite advantage in your quest to pwn it.

Trouble is, it's not so easy anymore.  There is a vast array of technologies that make up today's web application development landscape.  Not only are there are different types of web servers, application servers, and  programming languages, you also have to consider different development platforms (Java vs. .NET vs. something else), client-side JavaScript frameworks (Angular vs. React vs. something else), authentication protocols (OAuth vs. Kerberos vs. one-off vs. API token vs. something else), CMSs, CDNs, advertising networks, analytics engines, and so on.  Is your head spinning yet?

For quick feedback on what technologies a web application is using, I recommend the Wappalyzer browser extension.  It is available for both Chrome and Firefox.  Once installed, you will see the following icon in your browser's toolbar: 

Click this icon and you'll see a categorized listing of different types of technologies used by the website currently loaded in your browser.  Here is an example:

I have personally found this extension to be very useful... for pen testing or even when you see an interesting-looking site.  Find out what it's built on!  This extension thankfully works with Firefox 55 and later, which is something that can't be said of many popular Firefox extensions nowadays (this is thanks to Mozilla's shift to use the cross-browser WebExtensions API.

One last important note about Wappalyzer - you probably want to uncheck the option (shown below) where you send them "anonymous" reports for research.