AppSec Notes

The Gartner MQ for Application Security Testing Is Losing Relevance

noreply@blogger.com (Dave Ferguson) — Sat, 10 Jun 2023 23:00:00 +0000

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!

noreply@blogger.com (Dave Ferguson) — Wed, 17 Aug 2022 13:51:00 +0000

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:

Some common asymmetric algorithms include:

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:

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

noreply@blogger.com (Dave Ferguson) — Tue, 02 Aug 2022 22:36:00 +0000

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

noreply@blogger.com (Dave Ferguson) — Tue, 31 May 2022 23:36:00 +0000

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

noreply@blogger.com (Dave Ferguson) — Wed, 13 Apr 2022 20:47:00 +0000

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

noreply@blogger.com (Dave Ferguson) — Sat, 07 Oct 2017 20:05:00 +0000

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

noreply@blogger.com (Dave Ferguson) — Thu, 28 Sep 2017 05:05:00 +0000

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

noreply@blogger.com (Dave Ferguson) — Wed, 30 Aug 2017 05:00:00 +0000

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.

Quick (but telling) IE vs. Chrome Comparison

noreply@blogger.com (Dave Ferguson) — Tue, 18 Jul 2017 03:52:00 +0000

The following "perfect timing" slideshow on MSN is entertaining, so my first thought was that IE would be the best browser with which to view it. It's *MS*N after all. Firefox is my main browser, but I like to fire up alternatives from time to time to understand the experience (well, except for Edge which still sucks).

http://www.msn.com/en-us/lifestyle/smart-living/photos-taken-at-the-perfect-time/ss-BBEzdUL?li=BBnbcA0&ocid=UE01DHP&fullscreen=true#image=1

Boy was I wrong about IE here. It was slow, flaky, and then starting giving me "long-running script" errors and offering to stop the script for me. Even after saying yes to stop the script, the whole browser eventually locked up on me. FAIL.

Contrast that to Chrome, which was fast and worked flawlessly displaying the slideshow

I didn't try Firefox, because I have NoScript installed and just didn't want to deal with getting the slideshow to work.

Let's say "TLS" instead of "SSL"

noreply@blogger.com (Dave Ferguson) — Wed, 08 Feb 2017 01:59:00 +0000

A trend I noticed within information security circles is to use the term "SSL" even when we mean "TLS". TLS is the newer and more secure replacement for SSL. All versions of SSL, even the latest SSLv3 flavor, are considered to be insecure at this point.

It's habit to say "SSL". Our infosec minds auto-translate it to "TLS", but there are interesting, concrete reasons that the IETF chose the name TLS back in 1999. In addition, words have meaning and many people who don't eat, drink, and sleep security aren't up to speed on the nuances of this stuff. This includes millions of IT personnel who are responsible for configuring servers in a secure manner. It also includes newbies who are entering the infosec field every day.

Information security professionals can be arrogant. If someone isn't as knowledgeable as them, then that person is called stupid. For example, application security experts tend to denigrate developers for writing insecure code. That bothers me a lot.

Here's another example:

So people who don't know about SSL vs. TLS are not clever. Nice.

Years ago I didn't know much about security. I was a developer and appreciated the opportunity to learn from others. So let us be technically accurate and use "TLS", even if it turns out to be a losing battle in the end.

Webinar - Intro to Security Testing

noreply@blogger.com (Dave Ferguson) — Fri, 27 Jan 2017 06:05:00 +0000

I haven't done much blogging for a while. I will be doing more posts this year. At least that's one of my new year's resolutions! Some of my posts will be original content residing here, but others will be links to articles or posts I've done elsewhere.

I'd like to start 2017 by sharing a link to the webinar I did in 2015 that is aimed at anyone who wants to dip their toes into the world of web application penetration testing. The webinar was for the benefit of the uTest Community, and you therefore need an account to view the webinar. It's easy and free to sign up though.

I'm proud to say the uTest community has given my webinar a stellar rating of 4.86 stars out of 5! If you are new to the field of manual appsec testing, I'm sure you'll find it helpful. Pro tip: install and learn Burp Suite!

The webinar is here:
https://www.utest.com/courses/recorded-webinar-introduction-security-testing-dave-ferguson

Enjoy.

OWASP #4 Continues to Laugh at Automated Scanners

noreply@blogger.com (Dave Ferguson) — Wed, 17 Jun 2015 01:46:00 +0000

I was thinking back to 2006 when I was new to the world of Application Security. Someone on our consulting team arranged a call with a vendor called Secure Software, Inc. They were a company with a code scanning product called CodeAssure, but they were probably best known for a freeware tool called Rough Auditing Tool for Security ("RATS"). The company was bought by Fortify in 2007 and their products essentially died off.

On the call I wanted to better understand how this magical CodeAssure product worked. For example, how could it recognize Insecure Direct Object Reference in a web application? (Actually, that term wasn't even coined yet. Back then it was called Broken Access Control. Come to think of it, I like that name better.) Anyway, I described some of the vulnerabilities I was seeing during my application pen testing where I could edit numerical parameters in the URL or the HTTP request body and gain access to another user's data.

For a moment, there was dead silence on the call. It was one of those times when nobody on their side knew how to answer and they were all hoping that one of their teammates would step up and offer an intelligent response. In the end there was no intelligent response, only dancing around the question as sales people often do. I was a little naive back then to ask the question in the first place. I should have known their product could do absolutely nothing to identify this type of vulnerability.

SAST scanning tools can't be relied upon to identify insecure direct object references. But hey, the same is true for dynamic scanners. DAST tools aren't human and aren't smart enough to know that if you change acct_id=100011 in a URL to acct_id=100012 and you get back a valid response with another person's data that it's a big freaking problem. The exploitability rating of this flaw is off the chart. Almost anyone can perform the attack and it is still happening today. Even big companies that pay attention to security like Citibank can succumb.

The bottom line in my opinion is that you can't use one security testing technique and have confidence that your apps are secure. Multiple testing approaches are needed for the best assurance. Obviously, cost is a factor here, but for your most business-critical applications, I would use SAST, DAST, and manual pen testing. Techniques like IAST and RASP are making strides and have much promise as well. Both of these are going to require development teams to be more involved (and accountable) for application security however.

Bug in WebEx Productivity Tools Exposed Audio Conference Credentials

noreply@blogger.com (Dave Ferguson) — Fri, 22 May 2015 15:52:00 +0000

I recently found a security bug in Cisco's WebEx Productivity Tools. The bug caused your audio conferencing credentials to be sent out in meeting invitations. It was limited in scope to InterCall customers who integrate with WebEx.

Background:
InterCall is an audio conferencing solution and can be used as an alternative to WebEx's built-in audio. My company is starting to roll out WebEx this way. InterCall users have a dedicated conference code and a leader PIN which are your account credentials. The conference code is meant to be public, but the leader PIN is like a password and should be kept confidential. Productivity Tools (PT) is an add-on product for WebEx customers. One of the key features is an integration with Outlook that allows you to create WebEx meetings and send out the invitations from within Outlook.

The Discovery:
First I set up WebEx to use my InterCall account for audio and then downloaded and installed WebEx PT. Next I created a test WebEx meeting from within Outlook and invited one person. Upon clicking "Send", PT securely communicated to the WebEx server to auto-populate the conferencing information in the meetng invite. When the information appeared, I saw my InterCall leader PIN just for a moment before the email was sent. At first I thought it was a mistake, but inspection of my Sent Items folder showed that my PIN was indeed sent. The person who received the invite confirmed he got my PIN as well. Wow! How could no one at Cisco or my company notice this? I was unable to find a work-around except for avoiding PT altogether by logging into the WebEx site and creating a meeting from there.

The WebEx meeting host key was also exposed in the email, but that wasn't too worrisome because it changes with each meeting.

The Fix:
I reported this security threat to Cisco (and InterCall) on April 28th. After pestering them for updates, Cisco Engineering finally confirmed to me on May 14 that it was a defect and that they were working on a fix. I can now confirm that the bug has been fixed in WebEx Productivity Tools Version 2.36.13013.10003, which was released on May 19, 2015. I would like to thank both InterCall support and Cisco PSIRT for their attention to this matter. For reasons that are unclear, Cisco hasn't released a security advisory or security alert about this issue This blog post will have to suffice.

I'd like to be able to say that technical acumen and advanced hacking were needed to find this vulnerability. Alas that was not the case! I was just curious about my new WebEx toy, wanted to understand how it worked, and stumbled upon it. Being curious and questioning things... it's what people in information security tend to do.

Update: On May 28th I received an email from WebEx notifying me about the patch for the vulnerability:

I Cut My Payment Card in Half and What I Found Surprised Me

noreply@blogger.com (Dave Ferguson) — Sun, 07 Dec 2014 22:59:00 +0000

Recently I received an American Express card from Citibank to replace my expiring one. Naturally, I cut the old card in half. My customary procedure is then to discard one of the pieces in a trash receptacle at my house and the other piece in a different trash receptacle. I figure this will keep me pretty safe from dumpster-diving fraudsters because the trash receptacles are typically emptied at different times and go into different plastic trash bags.

This time I decided to examine the pieces of my card. What I found was that having only the right-side piece would allow someone to reconstitute the full 15-digit account number! Given where I cut the card, which was pretty much right down the middle, the front showed the last 7 digits and the back showed the first 8 digits. See the photos below (numbers masked for the protection of me).

What's more, the 4-digit security code appeared on the front side and my full signature was visible on the back (also masked for my protection). At least the security code was different on my new card, so once activated, using the old code should cause a payment authorization failure. Still, many e-commerce sites do not require the security code when making a purchase.

So with just half of my old card, the expiration date is the only unknown to a dumpster diver. That is not a big obstacle to overcome at all. Logically, if someone throws away a payment card, the probable reason is that he/she received a new card to replace the expiring one. What would be the expiration date of the new card? It's very likely to be either two years or four years from now - either the current month or the subsequent month.

This reminds me of the story of the torn-up credit card application that I read about a few years ago. A man named Rob Cockerham taped the pieces back together, filled out the application, and sent it in. Amazingly, a shiny new card arrived in the mail for him a few weeks later.

The bottom line is: Be aware that if you cut up your debit cards or credit cards and throw the pieces away in different receptacles like me, you're not necessarily safe from dumpster diving.

I'm asking for a shredder for Christmas.

Wordlist for Common Pet Names

noreply@blogger.com (Dave Ferguson) — Fri, 21 Nov 2014 05:12:00 +0000

If you are testing web applications for security, be sure to examine the Forgot Password functionality and attempt to subvert it. It's another way that users can authenticate to the app and is often less secure than the primary method. First you'll need to enumerate usernames (try the username wordlists I made available a while ago). Once you have some valid usernames, the Forgot Password functionality will often present you with a challenge to answer one of the user's personal security questions.

One of the most common security questions you see is "What was the name of your first pet?". If the application doesn't limit the number of attempts, you have a very good chance at answering this question by iterating through different names with a tool like Burp Intruder. The last time I did this successfully, "Rocky" was the name of the user's pet.

You need big list of common pet names to do this. That's exactly what I'm providing here for your download pleasure. My wordlist currently has over 1,400 pet names.

Click here to get the pet name wordlist

Enjoy! Obviously my list can't cover every conceivable pet name, but please let me know if you think I'm missing a common one.

Disabling SSLv3 in Firefox

noreply@blogger.com (Dave Ferguson) — Thu, 30 Oct 2014 20:32:00 +0000

With the recent discovery of the POODLE vulnerability in the SSLv3 protocol, I wanted to change my Firefox configuration to disallow SSLv3. Mozilla released an extension for this called SSL Version Control, but I decided not to install it given its somewhat sketchy reviews.

No problem I thought. Time to open the advanced configuration in Firefox by entering "about:config" in the address bar and make the change there. Searching for "security", will show many configuration settings that start with "security.ssl3". Some of them will be set to true and some to false. You would think setting all the values to "false" here would be the solution. Nope! Don't do it. Although the settings have "ssl3" in their name, they actually apply to both SSLv3 and all three TLS versions (1.0, 1.1, and 1.2). If you change them all to false, both SSLv3 and TLS will be disabled and your browser will be incapable of communicating securely at all.

The correct solution, as described here, is easier. Just set "security.tls.version.min" to 1, which means that TLS v1.0 is the minimum allowed version. When set to 0, it means that SSLv3 is allowed. I hope that helps.

This is a temporary work-around anyway as Mozilla says that SSLv3 will be disabled by default starting with Firefox 34.

Building Secure Applications: How Mature Are You?

noreply@blogger.com (Dave Ferguson) — Fri, 01 Aug 2014 00:15:00 +0000

I was invited again to contribute to the blog of application security company Checkmarx. My second post was published a couple of days ago and covers software security and the Building Security In Maturity Model (BSIMM).

Implementing Forgot Password with Email

noreply@blogger.com (Dave Ferguson) — Sat, 26 Apr 2014 03:31:00 +0000

It turns out that application developers sometimes need to implement a forgot password feature but don't have much identity data about the users in the system. Neither can they always be so flexible as to require users to establish personal security questions. These things are a key part of my forgot password security recommendations. But the reality is that sometimes you don't have any information about a user except their username and email address. Heck, sometimes email address IS the username.

In this type of situation, implementing a secure forgot password feature is challenging. Sending a password reset link via email is probably the best option (barring a non-automated solution where users call customer support). So here I will offer up some specific ideas on how to secure the process when using email.

When a user invokes the forgot password process, don't say anything about whether the username entered was recognized or not. It should simply display a generic message such as: "Thank you. If the username you provided is valid, we will send you an email with instructions on how to reset your password".
Along with the above, don't show the email address where the email was sent. It might give legitimate users a warm, fuzzy feeling but it definitely helps attackers in a number of scenarios.
The password reset link in the email message should incorporate a GUID or similar high-entropy token. The token could be a parameter in the query string or part of the URL path itself. It doesn't really matter.
Allow only one valid token per user at any given time.
Make sure the email message does not include the username.
Make sure the link can be used only once. In other words, invalidate the token immediately when an HTTP request containing that token is received.
The link should expire. Depending on your situation, implement logic to invalidate the token 10, 20, or 30 minutes after the email is sent out. Make it a configurable value so it can be adjusted if needed without a code change.
The password reset page (the one that appears after clicking the link) should force the user to re-enter his username.
If the username entered is incorrect 3 times in a row, lock the account. Remember, your application knows which username is associated with the token. The person attempting to reset the password should know it as well.
After a successful password reset, send a confirmation email to the user to notify them it happened. This can alert users to fraud if they didn't initiate it.
Throughout each step of the process, make sure the application is logging everything that occurs so there's a solid audit trail in case something goes haywire.

So those are the mitigating controls I came up with. Feel free to let me know in the comments if you have any other ideas!

(updated on May 5, 2014 based on some feedback I received)

Autocomplete="off" Now in Disfavor

noreply@blogger.com (Dave Ferguson) — Wed, 16 Apr 2014 18:07:00 +0000

In case you missed it, both IE 11 and Chrome recently made a change and they now ignore autocomplete="off" on password input fields within HTML pages. This attribute is something I've always recommended for input fields that contain sensitive data so that browsers won't store the data locally where it could be compromised. Apparently the changes were made solely because lots of people are using password managers. Here's a snippet from a messy MSDN blog post that tries to explain the reason for changing IE:

Password Managers improve real-world security, and the IE team felt it was important to put users in control. Users rely on their password manager to permit them to comfortably use strong passwords. Password managers encourage strong, unique password creation per site, but unique, strong passwords are often difficult to remember and type on touch devices. If the browser doesn't offer to autocomplete a password, the user assumes that the browser is broken. The user will then either use another browser that ignores the attribute, or install a password manager plugin that ignores it.

I'm not sure I agree. Moving to another browser would not have worked since they all honored the attribute until recently. It is also stated plainly that users could use a password manager plugin to overcome the restriction.

And here's a snippet from a message posted by the Chrome team with their reasoning:

We believe that the current respect for autocomplete='off' for passwords is, in fact, harming the security of users by making browser password managers significantly less useful than they should be, thus discouraging their adoption, making it difficult for users to generate, store, and use more complex or (preferably) random passwords.

Maybe I don't understand the decisions because I don't use a password manager. Either way, it is good that all browsers continue to honor autocomplete="off" for non-password inputs (type="text") so that sensitive data such as credit card numbers can be protected.

A Basic Application Security Quiz

noreply@blogger.com (Dave Ferguson) — Sun, 09 Mar 2014 23:25:00 +0000

Do you know web application security? Here is a little 10-question quiz to find out. I've interviewed quite a few people for AppSec jobs in the past and asked these type of questions. I thought it would be fun to share. Answers are at the bottom along with your ninja score. Don't cheat by googling for answers!

1. As a web application user, what puts you at most risk to fall victim to a cross-site request forgery (CSRF) attack?
a) Using an old browser
b) Using a web app that is not fully protected by SSL/TLS
c) Using the "keep me logged in" option offered by web apps
d) Using weak passwords

2. TRUE or FALSE? All web applications are vulnerable to CSRF attacks unless there's a specific protection mechanism in place.

3. TRUE or FALSE? An attacker could use a cross-site scripting (XSS) flaw on a banking site to steal login credentials while the victim appears to remain on the legitimate banking site.

4. If you want your web application to defend itself against cross-site scripting attacks that steal session IDs, which cookie attribute is best able to help you?
a) Secure
b) Path
c) Expires
d) HttpOnly

5. TRUE or FALSE? The best way to eliminate SQL injection vulnerabilities in code is to validate input data.

6. TRUE or FALSE? Using POST requests with hidden form fields provides a significant level of protection against attackers who want to tamper with requests.

7. What is one way developers can defend against forced browsing attacks?
a) Incorporate GUIDs into file names
b) Log all user activity
c) Validate input data
d) Use a sensible directory naming scheme

8. A race condition in a web application can lead to a security hole. Which software analysis technique is best suited to identify the existence of a race condition?
a) A manual penetration test
b) A dynamic (blackbox) automated scan
c) A static (whitebox) scan
d) Functional tests by QA team

9. Your web application allows users to download their account statements in PDF format. What is the most secure way to implement this functionality?
a) Store all PDFs in an obscure directory on the web server and provide a link to the correct PDF depending on the user.
b) Generate the PDF on the fly, write it to a temporary directory on the server, and redirect the browser to that location (via 302 response).
c) Generate the PDF on the fly, store it in memory on the server, and send the bytes of the PDF to the browser directly (via 200 response).
d) Store the PDFs in a database and retrieve the correct PDF by looking at the identifier/primary key provided in the HTTP request.

10. TRUE or FALSE? Most web applications provide only one method of authentication, namely username + password.

ANSWERS

1. Answer: c
With the "keep me logged in" option, a persistent cookie is set causing you to be in a permanently-authenticated state. A key factor in a successful CSRF attack is that the victim is authenticated to the target site.

2. Answer: FALSE
Read-only web apps (no actions can be taken by a user) are not subject to CSRF attacks.

3. Answer: TRUE
With XSS, a login form having an action attribute that points to the attacker's site could be created via JavaScript on the legitimate site.

4. Answer: d
The HttpOnly attribute of a cookie instructs web browsers that JavaScript is not allowed to access the cookie. This means that malicious JavaScript injected in an XSS attack can't access the cookie. (HttpOnly is widely supported by web browsers)

5. Answer: FALSE
Using parameterized queries with data binding is the best way. That said, input data validation should always be done.

6. Answer: FALSE
Many free tools are available that make it easy for anyone to edit HTTP requests prior to being sent to the server.

7. Answer: a
Using GUIDs (globally unique identifiers) makes it near impossible for a user to guess valid file names. A problem I've seen frequently when doing pen tests is that the application names static files such as PDF or Excel documents in a logical, consistent manner. For example, a file name might include the user's name or account number. This could make it easy for one user to guess the name of other files and access information intended for other users.

8. Answer: c
Static analysis theoretically has full insight into the whole codebase and should be able to spot a situation where multiple threads compete for the same resource. With dynamic/run-time testing, it can't be guaranteed the race condition will ever manifest itself. If you've ever tried to reproduce a deadlock problem in a piece of software, you know how very difficult it can be.

9. Answer: c
Because the PDF is never written to disk in option c, there is no chance an attacker can forcefully browse to it. Option d is not secure because a user could tamper with the identifier to access another user's document.

10. Answer: FALSE
Most web applications provide TWO methods of authentication. One is username + password. The other is some sort of Forgot Password mechanism, which is often created as an afterthought and less secure than it needs to be.

SCORING

Answers Correct AppSec Ninja Level*

9-10 Kage

7-8 Jounin

5-6 Chuunin

3-4 Genin

0-1-2 Academy student

* Based on Naruto Rank

Software Bugs That Kill

noreply@blogger.com (Dave Ferguson) — Wed, 19 Feb 2014 23:29:00 +0000

You might remember the rash of unintended acceleration incidents that occurred in Toyota vehicles a few years ago. Perhaps the worst incident happened near me in Southlake, Texas where four people were killed. I remember thinking at the time that these incidents had all the indicators of a software problem. Well it turns out that is most likely the case. Research from an embedded software expert as part of an Oklahoma trial indicates that a stack overflow may be responsible.

The Toyota issue reminded me of the story of the Therac-25. Every computer science student should be required to read it. The Therac-25 was a medical linear accelerator that used electrons to create high-energy beams to destroy tumors in cancer patients. Eleven of these devices were built and used in the 1980s. Software bugs in the Therac-25 caused massive overdoses of radiation that killed patients.

Here are some quotes from the story. It reads like a novel.

she felt a "tremendous force of heat . . . this red-hot sensation." When the technician came in, the patient said, "You burned me." The technician replied that that was not possible.

She completely lost the use of her shoulder and her arm, and was in constant pain. She had suffered a serious radiation burn, but the manufacturer and operators of the machine refused to believe that it could have been caused by the Therac-25.

the patient said that he felt like he had received an electric shock or that someone had poured hot coffee on his back: He felt a thump and heat and heard a buzzing sound from the equipment. Since this was his ninth treatment, he knew that this was not normal. He began to get up from the treatment table to go for help. It was at this moment that the operator hit the "P" key to proceed with the treatment. The patient said that he felt like his arm was being shocked by electricity and that his hand was leaving his body.

Software quality is really important. The reality is that some bugs can lay hidden for a very long time because they surface only under a very rare set of circumstances. A race condition (multiple threads competing for the same resource) is a good example of this. Another example is the security flaw in MySQL that allowed a 1 in 256 chance of *any* password to work.

Fortunately, most developers don't write code that can cause direct bodily harm, but I think it's good to be familiar with these types of cases and hopefully avoid repeating history.

Where To Practice Your Web Hacking Skills

noreply@blogger.com (Dave Ferguson) — Wed, 19 Feb 2014 05:26:00 +0000

I was invited to contribute to the blog of application security company Checkmarx. Last week my first post was published and covers some ways you can safely practice your web hacking skills.

Alternatives to the Boring XSS Alert Box

noreply@blogger.com (Dave Ferguson) — Wed, 08 Jan 2014 05:31:00 +0000

Demonstrating that a web application is vulnerable to reflected cross-site scripting (XSS) is not very exciting. It's always kind of like, "oh hey, look here, an alert box popped up when you clicked on that link". Scary. Dramatic. Not! I was looking for more interesting ways to show how XSS could be used. I figure the code is more likely to get fixed if you can make a memorable impression. I came up with a few options.

I'll present these techniques using 3 websites that are Internet facing and purposefully built to be susceptible to reflected XSS.

demo.testfire.net (operated by IBM)
www.webscantest.com (NT Objectives)
testasp.vulnweb.com (Acunetix)

All of the URLs here were tested successfully with Firefox 26, IE 11 with the XSS Filter disabled, and Chrome 31 with the "--disable-xss-auditor" command line option. Note - if you have the NoScript extension, you'll have to either disable it temporarily -or- allow scripts on the above domains plus sc0rn.com and disable the XSS protection.

First, there is the boring alert box that I'm trying to get away from:

Alternative #1 is to fill the victim's screen with unicorns and rainbows.

Alternative #2 is to Rickroll the victim (i.e., redirect to Rick Astley's famous 80's music video).

Alternative #3 is to display some HTML... a funny news story in this case. (in Firefox w/NoScript you may have to click refresh for this to work)

Feel free to use these or create your own. I think you'll agree these are definitely better than popping an alert box.

Lastly, I have a hilarious, but mildly racy (NSFW?) alternative. (in Firefox w/NoScript you may have to click refresh for this to work)

How I Keep Track of My Passwords

noreply@blogger.com (Dave Ferguson) — Sun, 22 Dec 2013 22:48:00 +0000

We all know that you shouldn't re-use the same password on different websites, but this is extremely difficult in practice considering the number of sites people use today. Password managers were developed to help solve the problem of remembering passwords. Some examples are KeePass, Password Safe, and LastPass. They work fine for many people. However, I personally don't like the idea of depending on a password manager. I want the ability to pull the correct password out of my brain in case I'm ever in a situation where I don't have access to the password manager. There's also a risk that your passwords could be compromised (this is true about any data that is stored, encrypted or not).

I have over 100 different passwords, but I don't have any problem remembering them. I don't write them down or use any sort of password manager. I came up with a system that enables me to remember my passwords. It works for me, so I'm sharing the technique in case anyone else thinks it might be helpful.

With my system, you only have to remember two things.

A core password.
Your scheme.

First, come up with a strong core password of about 8 or 9 characters. This core piece should be random gibberish and needs to have a lowercase letter, an uppercase letter, a number, and a special character. An example is kM92ax4!. Whatever you decide upon, memorize it.

Second, pick a scheme based on the website's domain name. The scheme is used to supplement your core password. As a simple example, your scheme could use the last 3 characters of the site's domain, add one letter to each (this is actually an encryption technique called "ROT1"), and append this to your core password.

So for the site "www.verizonwireless.com", we see the last 3 characters of the domain are "ess". Therefore the 3 additional characters would be "ftt" and your final password is kM92ax4!ftt.

For sprint.com, your final password is kM92ax4!jou.

For att.com, your final password is kM92ax4!buu.

Come up with a any scheme you want as long as it's based on the website domain. Here are some other possibilities:

Prepend the first character to your core password/append the last two
Capitalize one or two of the letters
Subtract two letters ("ROT24" encryption) instead of adding one
Look at the first two chars + last char of the domain, instead of the last three

You get the idea. The scheme remains constant, but your password changes. Whatever you decide, never tell anyone your core password or your scheme.

My system isn't perfect. It doesn't work on sites that have a short maximum password length (like 10) or onerous password requirements (like requiring you to change it every 90 days). But overall it has worked great for me.

Wordlists for Common Usernames

noreply@blogger.com (Dave Ferguson) — Mon, 09 Dec 2013 03:35:00 +0000

I made some wordlists a while ago containing common usernames. They have proven very useful to me when doing application penetration testing, specifically they are great to use as the payload for Burp Intruder.

I created the lists by taking the 10,000 most common last names in the United States and prepending a single letter (for example "dferguson" appears in the usernames-d.txt wordlist). There are wordlists for all letters except "i", "q", "x", and "z" (frankly, there aren't many first names that begin with those letters so it's a waste of time to try them).

Click here to get the username wordlists (zip)

One scenario where you might leverage these wordlists is a web application where the login page returns a different error message depending if a valid username is received versus and invalid username. Run Intruder on the login request and you can probably reap a nice set of valid accounts.

You'll also find a special wordlist called usernames-top100-each-letter.txt. This is perfect when you have limited time and want to maximize your potential to find a valid account. And there's another list called usernames-generic.txt, which could help you discover some test accounts. Of course you can combine these wordlists any way you want (even concatenate them together and try the whole darn thing).

Things get a little more complex if the web app requires an email address for login. You could certainly append "@gmail.com", "@yahoo.com", "@aol.com", etc. to the usernames. Separate wordlists could be created for each email domain, or you could just leverage the power of Burp Intruder to append the domain on the fly.

Answers Correct	AppSec Ninja Level*
9-10	Kage
7-8	Jounin
5-6	Chuunin
3-4	Genin
0-1-2	Academy student
* Based on Naruto Rank