DevelopSec

security training

by Leave a Comment

Two-Factor Authentication Considerations

There was a recent article talking about how a very small percentage of google users actually use 2-factor authentication. You can read the full article at http://www.theregister.co.uk/2018/01/17/no_one_uses_two_factor_authentication/

Why 2-Factor

Two-factor authentication, or multi-factor authentication, is a valuable step in the process to protect accounts from unauthorized users. Traditionally, we have relied just on a username/password combination. That process had its own weaknesses that many applications have moved to improve. For example, many sites now require “complex” passwords. Of course, complex is up for debate. But we have seen the minimum password length go up and limitations on using known weak passwords go up. Each year we see lists of the most common passwords to not use, some being 123456 or Password. I hope no one is using these types of passwords. To be honest, I don’t know of any sites I use that would allow this type of password. So many these days require a mix of characters or special characters.

The above controls are meant to help reduce the risk of someone just guessing your password, there are other controls to help try to limit brute forcing techniques. Many accounts offer account lockout after X number of invalid attempts. There are other controls that we also see implemented around protecting the username/password logic. None of these controls help protect against a user reusing passwords on another site that may be compromised. They also do not protect against a user falling for a social engineering attack to trick them into sharing their passwords. To help combat this, many sites will implement a second factor beyond username/password.

The idea of the second factor is that even if you have the username and password, you will not have this other piece of information. In most cases, it is a value that changes every 60 seconds or so, and is delivered over a protected channel. For example, the token used may be sent via SMS, a voice call, or created through a phone application like the Google Authenticator application. So even if the attacker is able to get your password, via a breach, brute force, or just lucky guessing, in theory they would not have access to that second factor.

Why Are People Not Using It?

So why do people not enable the second factor on their Google accounts? Unfortunately, the presentation didn’t appear to explain that, which makes sense since it is difficult to know why people do or do not do certain things. I think there may be a few reasons for it that we will briefly touch on.

First, I think many people just are not aware of enabling the second factor. To be fair, it is sort of buried down in settings that may be difficult to find if you are not really looking for it. If it is not front and center, then there is a much smaller chance people will go seeking it out. To add to the issue, many people really don’t understand what 2-factor authentication means or how it really helps them. Sure, in security we get it, but that doesn’t mean everyone else does. How do we make it more prominent that this is a positive security feature? Many users will already be aware of 2-factor if they use online banking as most of those have started enforcing it.

Many people think that two factor authentication is a burden or it will slow their access down. This is usually not the case unless the application has implemented it poorly. Many sites will allow you to save your computer so you don’t need to enter the 2nd factor every time you access the site. However, it will require it if you access from a different computer.

To complicate things, other applications may not support signing in with 2 factors, like your email client. In these cases, you have to generate an app password which can be very confusing to many users, especially those that are not technically savvy.

There may be a chance that users don’t think they need to protect their email accounts, that it is not sensitive. If you just use email to communicate with friends and receive junk mail, what could be so bad, right? Most people forget that things like password resets are performed using an email account. Having control of an email account provides a lot of control over a lot of things. While it may seem small, email is an important function to protect.

If you are using Gmail, I recommend configuring 2-factor authentication. The following video walks through setting it up using SMS (Although there are other options as well):

Demo- Google 2 factor

If you are developing applications, I recommend looking into providing the option of 2-factor authentication. When you do this, make sure that you are promoting its use in a positive way. If you already have 2-factor with your application, can you run a report to determine what percentage of users are actually using it? If that number is low, what steps can you take to increase them?

Don’t assume that any application is not worthy of the extra security. Many applications are already providing 2-factor and that number will just increase. While we still have the password, we will always be looking for ways to add more protection. When implemented properly, it is simple for the end user, but effective in increasing security. If your user base is not taking advantage of the option, take the time to assess why that is and how it can be improved.

As I was writing this up, I ran into an interesting situation with 2-factor that sparked some more thoughts. When looking to support 2-factor authentication and not using SMS, take careful consideration to the applications you may choose to support. On the Apple App Store alone there are over 200 different authenticator apps available. Some are interchangeable while others are not. This can be another barrier in users choosing to enable 2-factor authentication.

by Leave a Comment

Tinder Mobile Take-Aways

While browsing through the news I noticed an article talking about the Tinder mobile app and a privacy concern. You can read the article at https://www.consumerreports.org/privacy/tinder-app-security-flaws-put-users-privacy-at-risk/. To summarize what is considered the issue is that the mobile application does not transmit the photos that you see using HTTPS. This means that anyone on the same connection can see the traffic and, ultimately, see the photos you are presented. From my understanding, it doesn’t appear the potential attacker can tell who the user is that is viewing these photos as the rest of the traffic is properly using HTTPS.

We have discussed the move to all HTTPS multiple times on this blog and we are seeing a lot of sites making the switch. With web applications it is easy to see if the site is using HTTPS or not with the indicators near the address bar. Of course, these indicators are often confusing to most, but at least we have the ability to see the status. With a mobile application it is much more difficult to tell if data is transmitted using HTTPS or not because there is no visible indicator. Instead, one needs to view the raw traffic or use a web proxy to see how the data is transmitted. This can be misleading to many people because the assumption is that the data is protected because it is hidden under more layers.

In this instance, the ability to see these photos may not be considered that sensitive by many. Assuming that anyone can create an account and see the photos doesn’t make them a secret. People have opted to post their images for others to find them on the network. Of course, level of sensitivity is in the eye of the beholder these days. Another issue that is potentially possible in this situation is that the attacker could manipulate that image traffic to show a different image. This could lead to the end user seeing a different image than the one expected. The usefulness of this could be called into question at any type of large scale.

The take-away here is that when we are building applications we must take care in understanding how we are transmitting all of our data to determine what needs to be protected. As I mentioned, there is already a push to make everything HTTPS all the time. If you have decided not to use HTTPS for your connections, have you documented the reasons? What does your threat model tell you about the risks with that data and its communication. How does that risk line up with your acceptance procedures.

Another interesting tidbit came out of the article mentioned above. In addition to seeing the actual photos, they found it was possible to identify whether or not the end user liked or disliked the photo by comparing the network traffic. The interesting part about this part is that those decisions were encrypted when transmitted. The key point here is that the traffic for each decision was a set size and the sizes were different for like and dislike. By viewing the traffic after seeing a photo, it is possible to determine which ones were liked based on the size of the requests. In this case, it still doesn’t identify the end user that is using the application.

We don’t typically spend a lot of time analyzing the size of the requests we send in the event someone may try to determine what actions we are taking over an encrypted channel. Most of the time these actions are not possible to determine, or the level of effort is way above what is realistic. The easy solution would be to make sure all traffic was encrypted and we wouldn’t be able to know what images were liked or disliked. Maybe it would be possible to still see the difference, but with no way to tie it to specific images. The other option is to attempt to pad the requests so that they are all the same size. This would be for highly sensitive systems as the complexity may not be worth the benefit.

Of course, all of this is based on the attacker being on the same network as the end user so they can intercept or view the traffic in the first place. In the case of a public place, it might just be easier to hover over your shoulder and watch you use the app then intercept the traffic and guess at who is using it.

Both of these topics are good conversation starters within your organization. They help us realize that even just one request that doesn’t use HTTPS may be seen and could raise an issue. It also helps us to see that sometimes even encrypted data can be determined, but that doesn’t mean it is a high risk. Each situation is different and should be properly analyzed to determine the risk it creates for the company and the organization.

by Leave a Comment

Security Tips for Copy/Paste of Code From the Internet

Developing applications has long involved using code snippets found through textbooks or on the Internet. Rather than re-invent the wheel, it makes sense to identify existing code that helps solve a problem. It may also help speed up the development time.

Years ago, maybe 12, I remember a co-worker that had a SQL Injection vulnerability in his application. The culprit, code copied from someone else. At the time, I explained that once you copy code into your application it is now your responsibility.

Here, 12 years later, I still see this type of occurrence. Using code snippets directly from the web in the application. In many of these cases there may be some form of security weakness. How often do we, as developers, really analyze and understand all the details of the code that we copy?

Here are a few tips when working with external code brought into your application.

Understand what it does

If you were looking for code snippets, you should have a good idea of what the code will do. Better yet, you probably have an understanding of what you think that code will do. How vigorously do you inspect it to make sure that is all it does. Maybe the code performs the specific task you were set out to complete, but what happens if there are other functions you weren’t even looking for. This may not be as much a concern with very small snippets. However, with larger sections of code, it could coverup other functionality. This doesn’t mean that the functionality is intentionally malicious. But undocumented, unintended functionality may open up risk to the application.

Change any passwords or secrets

Depending on the code that you are searching, there may be secrets within it. For example, encryption routines are common for being grabbed off the Internet. To be complete, they contain hard-coded IVs and keys. These should be changed when imported into your projects to something unique. This could also be the case for code that has passwords or other hard-coded values that may provide access to the system.

As I was writing this, I noticed a post about the RadAsyncUpload control regarding the defaults within it. While this is not code copy/pasted from the Internet, it highlights the need to understand the default configurations and that some values should be changed to help provide better protections.

Look for potential vulnerabilities

In addition to the above concerns, the code may have vulnerabilities in it. Imagine a snippet of code used to select data from a SQL database. What if that code passed your tests of accurately pulling the queries, but uses inline SQL and is vulnerable to SQL Injection. The same could happen for code vulnerable to Cross-Site Scripting or not checking proper authorization.

We have to do a better job of performing code reviews on these external snippets, just as we should be doing it on our custom written internal code. Finding snippets of code that perform our needed functionality can be a huge benefit, but we can’t just assume it is production ready. If you are using this type of code, take the time to understand it and review it for potential issues. Don’t stop at just verifying the functionality. Take steps to vet the code just as you would any other code within your application.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

by Leave a Comment

SSL Labs and HSTS

Qualys recently posted about some grading changes coming to SSL Labs in 2017. If you are not aware of SSL Labs, it is a service to check your SSL/TLS implementation for your web applications to determine how secure they are. While there were more changes listed, you can read about them in the link above, I wanted to focus on the one regarding HTTP Strict Transport Security (HSTS).

If you haven’t heard of HSTS, or want a quick refresher, you can check out this post: HTTP Strict Transport Security (HSTS): Overview.

According to Qualys, the changes regarding HSTS will not be implemented until later in 2017, not with the initial set of changes. However, this early notification may help some companies make preparations for the change. Here is what they say about HSTS grading changes:

  • HSTS Preloading required for A+
  • HSTS required for A

Some organizations have specific requirements to the grade they expect to receive on the SSL Labs report. If an A is your target, HSTS is going to be a critical component for that. Even if it is not, this change is a clear indication that HSTS does not look like it is going away.

HSTS is a great way to help increase the security of your transmission from browser to server. However, it may not be something that can just be turned on. We have seen many sites have difficulty going to 100% HTTPS, and HSTS doesn’t play well with mixed content. It also doesn’t play well with self-signed certificates. While these are important for the increased security it provides, this is where the difficulty may come in.

If you are not using HSTS currently, now may be the time to start thinking about it. Creating the header is typically not very difficult. Testing to make sure nothing breaks because of it can be a bit more tedious. Want to know more about HSTS or application security?

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

by Leave a Comment

SDLC: Understanding your Roles

Application security should be on the mind of anyone that is part of the application design/build process. That means architects, developers, application owners, QA testers, business analysts and even end users. Everyone of these positions plays a role in the security of the applications. Depending on the organization, the roles can be quite different. You must understand the roles of these positions from a development perspective to really understand how they fit into the security aspect of the machine.

The first step in the process is to define and document each role in the SDLC. The goal is to understand each role’s relation to your SDLC. Usually the size of the development teams indicate the number of roles that may be implemented. Here are a few things to think about when you are defining your roles:

  • Who defines business requirements – Often times the requirements get spread across different teams. Ideally it is the application owner and business analysts working with end users to determine the requirements. However, often times many items are left up to the developers or database administrators to determine or define requirements. This is especially true around input validation or how data is stored.
  • Who directs the coding guidelines – In large enterprises it is common to see a centralized architecture group that defines coding guidelines across different teams. They may define if database access is limited to stored procedures or a specific ORM. In other situations it may be up to the individual developer. Is there a central input validation or output encoding framework?
  • Who determines database schema – When thinking about how data is stored, who defines the fields that are used, how they are protected (encrypted, hashed, plain text) and how the database is structured? Does the table layout make sense? Is it properly segmented?
  • Who tests the application – The quick response is the QA team, but developers are most likely responsible for testing as well. What about third parties, whether they be an internal security team, a client team or other 3rd party testing teams.

Understanding these roles and who is doing what is critical to maturing a secure SDLC program. Traditionally, the groups are often fairly separate, but as you start to look at the different questions you realize that many of these items are handled by multiple groups. It is that collaboration and communication that is also critical to maturing the SDLC.

The next step is to start identifying the people that are occupying these roles. What skillsets do they possess and do they line up with the role you just defined? This will ultimately lead to defining what training is required for each resource. Providing custom training that is specific to the groups needs is much more efficient and effective than just hosting a generic secure coding class. What if the group that needs training is QA or the business analysts? Developer training isn’t what is needed there. What if the group develops in .Net? A course written using Java will not be as effective.

Finally, we start to identify the processes for the SDLC from start to finish and look at what does and does not exist. From the processes that do exist, what role is responsible for that piece of the puzzle. There can be a lot of cogs in the development process, especially when we bring security into the picture. Think about things like static and dynamic analysis, which are part of most mature secure SDLCs. Do these exist, and if not, who will be the people involved with them when they are implemented?

Identifying the full process and what each role is doing is really the beginning of creating baselines for your program which we will cover in another post. This is critical because it provides a starting point so we can define where we are going. Like an asset inventory, you must understand the roles in the entire SDLC and what part they play. Once we start to truly understand our teams, we can start to make the adjustments needed to move forward in secure SDLC maturity.

by Leave a Comment

Security for QA Testers: The Importance

Quality Assurance (QA) testing is a critical role for any application that is being developed. The purpose: to identify flaws within the application that effect how the application runs and the users that use it. Typically this has focused on the goal of identifying flaws that prohibited the application functions from performing as expected. When I say expected, I mean that the end user is not able to complete his identified task.

Over the past decade there has been a growing focus on the missing QA testing focus: security flaws. What makes a security flaw different than the other flaws generally identified? Most security flaws, at least exploitable ones, focus on the ability to make the application do something it was not intended to do. If the application is supposed to allow me to view my bank account and I can make it show me someone else’s bank account it indicates a security flaw. The assumption here is that I shouldn’t be able to view another user’s account.

Typically in QA, the test would ensure that I could see my account and the data returned was in fact my information when I requested it. It does not check things like authorization issues to see what happens when I attempt to view another user’s account.

This is the time for QA to add this type of testing to their current test cases. Recently released reports attempt to show that the security field is suffering by a huge shortage. While we do have may different types of entities that will test our applications for security flaws, the best one is our own QA teams. Here are a few key indicators for why QA is so important in security testing.

Proximity
With the exception of the actual developers, no one is closer to the development phase than the QA team. You may have heard that a bug found in production costs a lot more to fix than one found in QA or development. There are multiple reasons for this, which we will cover in a different article. The key here is that we are getting almost a pseudo immediate feedback process for bugs found to send back to development. Not only does this mean we don’t lose the time of the application going through multiple other phases of the lifecycle only to be sent back, but the developers will adopt better secure coding techniques much quicker.

Application Knowledge
Many security flaws are based on the idea that we are able to make the application do something it was not intended to do. While some flaws like injection flaws don’t require any knowledge of the application functionality, authorization/authentication/logic flaws do require an understanding of the application. QA should have intimate knowledge of how an application should and shouldn’t work. Having this understanding makes it more efficient to understand what is a flaw and what is correct functionality.

Bug Tracking
Most likely, QA already has some sort of bug tracking system. Lets be clear, a bug is a bug is a bug. It doesn’t matter that it is a security bug, a simple logic flaw, or a typo in the UI, these bugs go through the same process. They get identified, logged, reported, analyzed, ranked/prioritized, and handled. It doesn’t make sense to have a separate system for managing bugs based on classification. Place an indicator if needed to indicate it is a security issue so that a report could be created to give to the infosec team for audit or review purposes.

We have an opportunity, as QA, to step up and take responsibility and ownership of enhancing our testing of applications. Is it different than your current tests? Probably. Can we do it? You bet. Lets start working on getting security built into our process instead of relying on a number of 3rd parties to do it for us. As we have seen, that doesn’t work so well.