DevelopSec

security research

by Leave a Comment

Overview of Web Security Policies

A vulnerability was just identified in your website. How would you know?

The process of vulnerability disclosure to an organization is often very difficult to identify. Whether you are offering any type of bounty for security bugs or not, it is important that there is a clear path for someone to notify you of a potential concern.

Unfortunately, the process is different on every application and it can be very difficult to find it. For someone that is just trying to help out, it can be very frustrating as well. Some websites may have a separate security page with contact information. Other sites may just have a security email address on the contact us page. Many sites don’t have any clear indication of how to report such a finding. Maybe we could just use the security@ email address for the organization, but do they have it configured?

In an effort to help standardize how to find this information, there is a draft definition for a method for web security policies. You can read the draft at https://tools.ietf.org/html/draft-foudil-securitytxt-03. The goal of this is to specify a text file in a known path to provide contact information for users to submit potential security concerns.

How it works

The first step is to create a security.txt file to describe your web security policy. This file should be found in the .well-known directory (according to the specifications). This would make your text file found at /.well-known/security.txt. In some circumstances, it may also be found at just /security.txt.

The purpose of pinning down the name of the file and where it should be located is to limit the searching process. If someone finds an issue, they know where to go to find the right contact information or process.

The next step is to put the relevant information into the security.txt file. The draft documentation covers this in depth, but I want to give a quick example of what this may look like:

Security.txt

— Start of File —

# This is a sample security.txt file
contact: mailto:james@developsec.com
contact: tel:+1-904-638-5431

# Encryption - This links to my public PGP Key
Encryption: https://www.developsec.com/jamesjardine-public.txt

# Policy - Links to a policy page outlining what you are looking for
Policy: https://www.developsec.com/security-policy

# Acknowledgments - If you have a page that acknowledges users that have submitted a valid bug
Acknowledgments: https://www.developsec.com/acknowledgments

# Hiring - if you offer security related jobs, put the link to that page here
Hiring: https://www.developsec.com/jobs

# Signature - To help secure your file, create a signature file and reference it here.
Signature: https://www.developsec.com/.well-known/security.txt.sig

—- End of File —

I included some comments in that sample above to show what each item is for. A key point is that very little policy information is actually included in the file, rather it is linked as a reference. For example, the PGP key is not actually embedded in the file, but instead the link to the key is referenced.

The goal of the file is to be in a well defined location and provide references to your different security policies and procedures.

WHAT DO YOU THINK?

So I am curious, what do you think about this technique? While it is still in draft status, it is an interesting concept. It allows providing a known path for organizations to follow to provide this type of information.

I don’t believe it is a requirement to create bug bounty programs, or even promote the security testing of your site without permission. However, it does at least provide a means to share your requests and provide information to someone that does find a flaw and wants to share that information with you.

Will we see this move forward, or do you think it will not catch on? If it is a good idea, what is the best way to raise the awareness of it?

by Leave a Comment

Insulin Pump Vulnerability – Take-aways

It was recently announced that there were a few vulnerabilities found with some insulin pumps that could allow a remote attacker to cause the pump to distribute more insulin than expected. There is a great write up of the situation here. When I say remote attack, keep in mind that in this scenario, it is someone that is within close proximity to the device. This is not an attack that can be performed via the Internet.

This situation creates an excellent learning opportunity for anyone that is creating devices, or that have devices already on the market. Let’s walk through a few key points from the article.

The Issue

The issue at hand was that the device didn’t perform strong authentication and that the communication between the remote and the device was not encrypted. Keep in mind that this device was rolled out back in 2008. Not to say that encryption wasn’t an option 8 years ago, for these types of devices it may not have been as main stream. We talk a lot about encryption today. Whether it is for IoT devices, mobile applications or web applications, the message is the same: Encrypt the communication channel. This doesn’t mean that encryption solves every problem, but it is a control that can be very effective in certain situations.

This instance is not the only one we have seen with unencrypted communications that allowed remote execution. It wasn’t long ago that there were computer mice and keyboards that also had the same type of problem. It also won’t be the last time we see this.

Take the opportunity to look at what you are creating and start asking the question regarding communication encryption and authentication. We are past the time where we can make the assumption the protocol can’t be reversed, or it needs special equipment. If you have devices in place currently, go back and see what you are doing. Is it secure? Could it be better? Are there changes we need to make. If you are creating new devices, make sure you are thinking about these issues. Communications is high on the list for all devices for security vulnerabilities. Make sure it is considered.

The Hype, or Lack of

I didn’t see a lot of extra hype over the disclosure of this issue. Often times, in security, we have a tendency to exaggerate things a bit. I didn’t see that here and I like it. At the beginning of this post I mentioned the attack is remote, but still requires close physical proximity. Is it an issue: Yes. is it a hight priority issue: Depends on functionality achieved. As a matter of fact, the initial post about the vulnerabilities states they don’t believe it is cause for panic and the risk of wide scale exploitation is relatively low. Given the circumstances, I would agree. They even go on to say they would still use this device for their children. I believe this is important because it highlights that there is risk in everything we do, and it is our responsibility to understand and choose to accept it.

The Response

Johnson and Johnson released an advisory to their customers alerting them of the issues. In addition, they provided potential options if these customers were concerned over the vulnerabilities. You might expect that the response would downplay the risk, but I didn’t get that feeling. They list the probability as extremely low. I don’t think there is dishonesty here. The statement is clear and understandable. The key component is the offering of some mitigations. While these may provide some inconvenience, it is positive to know there are options available to help further reduce the risk.

Attitude and Communication

It is tough to tell by reading some articles about a situation, but it feels like the attitudes were positive throughout the process. Maybe I am way off, but let’s hope that is true. As an organization it is important to be open to input from 3rd parties when it comes to the security of our devices. In many cases, the information is being provided to help, not be harmful. If you are the one receiving the report, take the time to actually read and understand it before jumping to conclusions.

As a security tester, it is important for the first contact to be a positive one. This can be difficult if you have had bad experiences in the past, but don’t judge everyone based on previous experiences. When the communication starts on a positive note, the chances are better it will continue that way. Starting off with a negative attitude can bring a disclosure to a screeching halt.

Conclusion

We are bound to miss things when it comes to security. In fact, you may have made a decision that years down the road will turn out to be incorrect. Maybe it wasn’t at the time, but technology changes quickly. We can’t just write off issues, we must understand them. Understand the risk and determine the proper course of action. Being prepared for the unknown can be difficult, but keeping a level head and honest will make these types of engagements easier to handle.

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.