DevelopSec

News

by Leave a Comment

Equifax Take-aways

By now, you must have heard about the Equifax breach that may have affected up to 143 million records of user people’s information. At this point, I don’t think they can confirm exactly how many records were actually compromised, leading to going with the larger of the numbers just to be safe. While many are quick to jump to conclusions and attempt to Monday morning quarterback what they did or didn’t do to get breached, I like to focus on what we can learn for our own organizations. There are a few topics I want to discuss that hopefully will be useful within your organization.

Patching

Well, it appears to be pretty clear that the avenue of attack was a Struts patch that was missing on the server. The patch was apparently released a few months prior to the attack, or at least acknowledgement of the attack. On the surface, patching appears to be a pretty easy task. A patch is released, you apply it.

Simple, right?

Patching is actually much more complex than that. It may be that simple when you have a single system to work with and maintain with very few software packages. Unfortunately, that is not the reality for so many places. Many organizations are dealing with hundreds or even thousands of systems to attempt to keep fully patched. This is a pretty big task, even if there were no other variables. Automate it they say. Sure, automation can be done, and needs to be done. How can anyone patch that many systems in a reasonable time frame manually?

There are other factors to consider. First, lets consider that there are many different types of patches. You have patches for the operating system, patches for applications, patches for frameworks, even patches for client-side libraries. Does your automation cover all of these sources? Some software has automatic update capabilities and will update on their own. Others require that you explicitly go out and download the patch and apply it.

Second, you have custom written applications with millions of lines of code pulling in multiple frameworks and packages to make development easier. It would be foolish to apply the patch without testing it first. This becomes more of a challenge with application patches because the entire application needs to be retested. This is more than a test to make sure the computer still boots. This needs to make sure that all the functionality, especially that functionality around the component is still properly functioning. The testing alone can be a time consuming piece. Add on to that if the patch makes any other changes within the code that breaks something. How bad does it break it. How much code needs to be rewritten for your custom code to work correctly again? Does that component have other components that are dependent on that version? Does this end up affecting other components?

Finally, who is tasked with patching the systems? Is this defined within the business? Are the same people that apply OS patches to the server the ones responsible for the application component patches? How do they track those type of patches? Do they need to get the go ahead from the application team that the patch is OK to implement?

As you can see, there are a lot of factors that go into apply what may appear to be a simple patch. What it highlights to me is the importance of understanding what components our application uses, how they interact with each other, and understanding how patches are applied when made available. Worst case scenario, we didn’t even know a patch was released.

Patching, however, is just one control for helping protect our systems. Similar to how input validation is a control to help with injection attacks. We shouldn’t be relying on it alone. The Equifax breach shows this well, that we must consider other controls in place in the event another control breaks down.

Encryption

I hear a lot of people talk about the data should have been encrypted. I believe that to be an easy statement to make, but without more details on how the data was actually accessed, it is not very helpful. Hopefully, your organization has a data classification policy. Hopefully, that data classification policy describes how data should be protected. This is the policy that determines how data should be protected and it should exist. If you have not seen this policy, ask for it.

Now that we know some data needs to be encrypted, what is the right method to use? Should we use disk encryption or column level encryption? Should we use Tokenization? The each have their pros and cons. Maybe the answer is you have to implement all of them, just to be safe, but how might that affect your ability to have a high performing functioning application?

You may decide to implement disk encryption for your database. That is a good step, in the event that someone is able to steal the actual files of the database. That doesn’t help much if the application has a vulnerability that allows access to the data that the attacker can just enumerate through. This can be similar to column level encryption as well. Often times application flaws may be able to bypass the encryption if incorrectly implemented. I guess at the very least, you get to say the data was encrypted.

The point with encryption is to make sure you know what you are doing and how you are implementing it. What attack vectors will it protect against and which ones may still be vulnerable. If you are going to take the time to implement it, it is important to make the best use of it.

Auditing and Logging

Auditing and Logging are important parts of the security of an application. They help us see and act upon events that may be malicious. How do you get vision into 3rd party components, like Struts, to see what they are doing? Are you relying on system event logs if the component throws an exception? Within our own applications we can use the logging to identify queries run, data accessed, and authorization failures, etc. When a system gets compromised, that logging may not be useful. It may be a combination of system and application events that help identify an attack as it is happening or after the fact. This is a great reminder that logging mechanisms can cross boundaries and this needs to be reviewed. Take a moment to look at how your applications and your web server are configured to identify potential malicious attacks. Consider different attack scenarios and see how those may get logged and if/when someone might see them.

Risk Management

Business run on the concept of taking risks. Sometimes this works in favor of the organization, sometimes not. In order to make better decisions, they must understand the risks they face. In a situation like this, we know there may be a patch available for a platform. The patch is critical since it allows for remote code execution. But what was known about the risk? What applications were effected on that server? What type of data did those applications maintain? Where does that application fit into our business model? Often times, we don’t look at the real details of a vulnerability or risk, rather we focus on the numbers. A patch that may compromise a system with no records and access is very different than one that relates to all your customer data that may be sensitive.

Don’t mistake this as an alternative to patch management. It is, however, a reality that in the midst of doing business, decisions will be made and not all of them will be popular. When working in your organization, think about the information you may be providing in regards to the decision making process. Is it sufficient? Does it tell the whole story?

Wrap Up

Companies are always at risk of being breached. As we see new breaches appear in the news we need to take a little time to skip the hype and personal opinions, and take a look at what it means to our programs. Look for the facts of what happened, how decisions may have been made, and the effect those had on the organization. Then apply that to your organization. Maybe you learn a new perspective on how a vulnerability can be used. Maybe you see a control that was bypassed that you also use and you want to review how your processes work. In any case, there are lessons we can learn from any situation. Take those and see how they can be used to help your processes and procedures to provide security in your organization.

by Leave a Comment

Blue Cross Mails USB sticks – Take-Aways

You have information you want to share with your customers, but how do you do it securely? How often have you heard not to click links sent via email? You shouldn’t plug in random USB drives to your computer. From a marketing perspective, how do you get large amounts of information, such as videos and specific information, out to your customers?

In a report by Fierce Healthcare (http://www.fiercehealthcare.com/privacy-security/bcbs-alabama-re-evaluates-usb-marketing-campaign-amid-security-concerns) it appears that BCBS of Alabama thought that sending out some fancy USB drives with benefit information was the right choice. Apparently the drive contained videos and other information about benefits for the company.

As you can guess, there was lots of skepticism around the method. We are taught in many security awareness training sessions to never plug untrusted USB drives into our devices. This is a common tactic used during penetration tests where they drop USB drives in the parking lot or in public places to see if someone will plug it in. Once plugged in, it may allow external access to the system for the attacker. Of course, this depends on the controls in place on the system it was plugged into.

You might wonder why we still see USB drives still passed out at conferences. There are still people that do this and you might consider those as trusted because you feel you received them in person. A company representative handed it to you, so it must be safe right? Well.. not necessarily. You should still proceed with caution.

In regards to mailing the drive, there appears to be an assumption of trust. This may be due to the fact that it was physically sent to you, vs. an item that was emailed. It came through the mail system, it had the corporate branding, even the right return address. The key factor is that all of those things can be spoofed. It is simple to create a letter with a company logo and branding and to set the return address to something other than your personal address. The mail system isn’t designed to verify trust in who sent a letter. Instead, it is meant to hopefully put trust in the fact that if you send mail, it will arrive at its destination.

Take Aways

When we analyze the situation, it helps us decide how to better review our systems to understand our risks and controls. There are a few things you can do to help reduce the risk of these types of potential attacks or situations.

Review your security awareness training to see how it covers USB drives and the policies around them. Are your users trained on how to handle a situation where they receive a USB drive from an untrusted source? Do they know who to contact to make sure it is properly analyzed before they attempt to use it?

Work with your marketing teams to determine how different campaign types work and which ones are acceptable. They are typically not considering the security aspect of every option and helping provide some insight goes a long way. It is not a matter of someone purposely trying to do something insecurely, but rather a situation where someone doesn’t have the exposure. Talk through the different scenarios and why they raise the risk level within the organization or to the clients.

Review any technical controls in place within the organization surrounding plugging devices into the computers. Do you have controls to block these devices? Is that control limited to storage devices? Remember that a USB drive can also be a Human Input Device (HID) which appears not as a storage device, but as a keyboard. These HID devices often bypass limitations on other USB drive types to allow executing code on the system.

Identifying alternative methods means calculating the risk of each one and picking the best choice. As an alternative, the campaign could have been an email campaign with a link in it for users to click. The risk is that people are taught not to click links in emails. Another option could have been to send the mail, but instead of the USB Drive, include a link for the user to type into their browser. It is recommended to use a link that goes to your domain, not a shortened URL. This provides more trust in that the destination is not hidden. Take the time to consider alternatives and the risks for each one.

by Leave a Comment

MySpace Account Takeover – Take-aways

Have you ever forgotten your password, or lost access to your accounts? I know I have. The process of getting your access back can range from very easy to quite difficult. In one case, I had an account that required that a pin code be physically mailed to me in 7-10 days. Of course, this was a financial account that required extra protections.

I came across this article (https://www.wired.com/story/myspace-security-account-takeover/) that identified that MySpace’s process for regaining access to an account was easily by-passable with just a few pieces of information that is commonly easily found.

According to the issue reported, the following details were needed to gain control of an account:

  • Account Holder’s Name
  • UserName
  • Date of Birth

In addition, the email address was part of the form, but was not actually validated.

With the amount of information available on social media platforms, and even though past breaches, it is very difficult to come up with good questions to help validate a user is who they say they are. In this case, the first 2 pieces of information are reportedly available on a user’s account page and are not difficult to find. It is critical that we give great consideration to the way we attempt to validate a user’s identity.

Security or secret questions have been known to be weak for a long time. While they can help provide some assistance in identifying the user, they should not be used alone. One recommendation is to include a side channel for some verification. For example, requiring a user to receive an email at the address on record before answering these questions helps reduce some of the risk. This method now requires that an attacker gain access to the user’s email account to receive a temporary account reset link. Although this is possible, it adds another hurdle to help protect the user’s account.

Similarly, you could look to send a code to a phone number that is currently on record. Like email, it would then require the interception of the phone message, adding difficulty to the process. One of the points here is that you only want to send to email or phone that is already on record. Never allow the user to provide a new email address or phone number as they could add an untrusted phone number and easily take over the account.

There was another piece of this that should be considered, the unvalidated email address. The request for the email address in this reset process may have been meant as another verification of account information. However, as commonly seen, the value wasn’t actually validated on the server. This is an easy oversight to make when working with web forms.

Remember that validation should always be performed on the server. This is because it is simple to bypass client-side validation with the use of simple add-ins or a web proxy.

Validation of data fields should be a standard part of QA testing. Ensure that when testing forms, such as the account recovery, that the form reacts accordingly with many types of inputs. This includes what happens if a field is not provided or if it does not line up with the expected answer. This same situation has been seen on other sites where the current password may be required to update the password, but is not actually verified.

These types of stories help remind us to review these types of functions and features within our application. For older applications, it may have been a while since we have touched these features and how they were designed initially is no longer recommended. Take a moment to look back at your account recovery process to make sure it is up to par with your current requirements.

Looking for some help with your application security program? Just want someone to talk to about these types of topics? Reach out to us. We are here to help and offer a wide range of services to help make your day easier. Reach out to james@developsec.com for more information.

by Leave a Comment

Using the AWS disruption to your advantage

By now you have heard of the amazon issues that plagued many websites a few days ago. I want to talk about one key part of the issue that often gets overlooked. If you read through their message describing their service disruption (https://aws.amazon.com/message/41926/) you will notice a section where they discuss some changes to the tools they use to manage their systems.

So let’s take a step back for a moment. Amazon attributed the service disruption to basically a simple mistake when executing a command. Although following an established playbook, something was entered incorrectly, leading to the disruption. I don’t want to get into all the details about the disruption, but rather, lets fast forward to considering the tools that are used.

Whether we are developing applications for external use or tools used to manage our systems, we don’t always think about all the possible threat scenarios. Sure, we think about some of the common threats and put in some simple safeguards, but what about some of those more detailed issues.

In this case, the tools allowed manipulating sub-systems that shouldn’t have been possible. It allowed shutting systems down too quickly, which caused some issues. This is no different than many of the tools that we write. We understand the task and create something to make it happen. But then our systems get more complicated. They pull in other systems which have access to yet other systems. A change to something directly accessible has an effect on a system 3 hops away.

Now, the chances of this edge case from happening are probably pretty slim. The chances that this case was missed during design is pretty good. Especially if you are not regularly reassessing your systems. What may have not been possible 2 years ago when the system was created is now possible today.

Even with Threat Modeling and secure design, things change. If the tool isn’t being updated, then the systems it controls are. We must have the ability to learn from these situations and identify how we can apply them to our own situations. How many tools have you created that can control your systems where a simple wrong click or incorrect parameter can create a huge headache. Do you even understand your systems well enough to know if doing something too fast or too slow can cause a problem. What about the effect of shutting one machine down has on any other machines. Are there warning messages for things that may have adverse effects? Are there safeguards in place of someone doing something out of the norm?

We are all busy and going back through working systems isn’t a high priority. These tools/systems may require an addition of new features, which makes for a perfect time to reassess it. Like everything in security, peripheral vision is very important. When working on one piece, it is always good to peek at other code around it. Take the time to verify that everything is up to date and as expected. Not any changes and determine if any enhancements or redesign is in order. Most of the time, these are edge case scenarios, but they can have a big impact if they occur.

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

Gmail will block JavaScript file attachments

According to a recent announcement, Gmail will start blocking .js file attachments starting February 13, 2017.

Blocking specific attachment types isn’t something that is new to Gmail. They already block attaching file attachments that are .exe, .msc, and .bat types. The recent move to add javascript files is most likely related to the recent malware/ransomware campaigns that have started using JavaScript files instead of Microsoft Office files. There was an article posted back in April discussing this trend.

If you are still looking to send another person a JavaScript file, you can just use other services, like Google Drive, Dropbox, or other similar products. While the change doesn’t block all potential avenues for ransomware to be sent via email, it does help reduce the risk of this particular method.

As a user, we still must be attentive to other attack vectors, such as macros within Microsoft Word files which can be used to infect systems. There may be a resurgence of these methods as the JavaScript files start getting blocked.

This move does beg the question as to why not force all attachments to go through a storage service, rather than directly attached to the email. Would that actually create a larger risk with the abundance of links now being sent within emails? Would it just move the threat from your inbox to the cloud service? It would be interesting to get a bigger picture of this landscape for better understanding.


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

Secure Notification Updates in FireFox and Chrome

There has been a steady increase in the number of applications that have switched to using HTTPS instead of HTTP for communication. Even sites that have no sensitive information or authentication mechanisms. Using HTTPS provides authentication and a secure channel to transmit data between client and server. The authentication verifies that you are communicating with the organization you thought you were. This secure transmission is meant to stop other parties from being able to read or manipulate the user’s traffic. For non-sensitive applications, it is that ability to manipulate the traffic that we are trying to protect against.

Mozilla announced that the next version of FireFox, Firefox 51, will be changing how it presents the lock icon to represent security issues with the site. Traditionally, there would be a green lock icon for secure sites and no lock icon for sites that use HTTP. The new changes will introduce a grey lock icon with a red slash through it when a site is using HTTP and collects passwords. In addition, there will be a note indicating that “Logins entered on this page could be compromised.”

Mozilla also hints at some additional changes on the roadmap. In particular, a potential indicator on the password field that will alert the user that the account details are insecure and may be compromised. It will be interesting to see how this feature will be implemented, especially if the browser will inject code into the application code. This could raise some concerns for many others out there.

Back in September, 2016, Google announced that Chrome was making similar changes that would take effect in January. I did a podcast on this which is included here.

Google is going further than just passwords and including credit card number fields. There wasn’t much mentioned for FireFox about anything other than passwords. In both browsers, changes should be available soon. Help spread the word about the new changes so your users, your friends, and your family know what the new indicator really means.

You may be surprised at the number, or type of sites that may be affected by this. There are many forums and other community sites that get created without using HTTPS for transmission. This may be because the site owner doesn’t realize the benefits of using HTTPS. They may also not think that the site contains sensitive information, so why add the overhead. However, many of these sites do require you to create an account and log in with a password. Unfortunately, many people re-use passwords so na attacker getting that forum password may have also just gotten your password for other sites. Not to mention, they could impersonate you on the specific site.

In the absence of sensitive or account information, using HTTPS provides protection from traffic manipulation. Even rising a corporate landing page, an attacker on the same network could inject malicious code into the response to attempt malicious activity on your system.

What are your thoughts? Are you for the browsers making these types of changes? Do you think it is an overreach? If so, why? Share your thoughts on twitter or join our slack channel to join the conversation (send me an email for an invite).


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.