Developer-First Security, Shifting Security Left With A Plan

The best way to solve the software security problem is when and where it starts, right at the software creation phase. Solving the problem after the software is written and deployed is like testing and fixing cars after they left the car manufacturing facility. Fortunately, the industry has already realized this and started integrating security controls and checks early on in the software development lifecycle.

Securing the Software Development Lifecycle

The first few iterations of securing the software development lifecycle focused on adding isolated activities to the software development organization. When these first few iterations came out, it was a time when most organizations were following a waterfall methodology.

One of the popular methodologies to integrate security into the Software Development Life Cycle is OpenSAMM (https://www.opensamm.org/).OpenSAMM defines 12 security practices divided among 4 business functions: Governance, Construction, Verification and Deployment. OpenSAMM goes afterward and describes 3 security practices with each business function.

  1. The Governance: a business function includes performing the following security activities: Strategy & Metrics, Education and Guidance, Policy & Compliance
  2. The Construction: business function includes performing the following security activities: Security Requirements, Threat Assessment and Secure Architecture
  3. Verification: a business function includes performing the following security activities: Design review, security testing and code
  4. Deployment: a business function includes performing the following security activities: Environment hardening, vulnerability management and operational enablement

SAMM Overview

SAMMoverview

You can see right away how the methodology makes the assumption that the business functions are nicely segregated from each other. OpenSAMM would work great for organizations that are working using Waterfall methodologies. Another popular methodology is Building Security In Maturity Mode (BSIMM), a popular methodology used by organizations like CapitalOne, Verizon and FreddieMac. Similar to OpenSAMM, the BSIMM framework consists of 12 practices organized into four domains: Governance, Intelligence, SSDL touchpoints and Deployment.

Building Security In Maturity Mode (BSIMM)

While BSIMM and OpenSAMM focus on integrating multiple security controls into the software development lifecycle (SDLC). Several challenges exist coming to implement these frameworks:

  1. Most of the time these activities are actually implemented by security teams, making it harder for developers to get onboard.
  2. A significant overhead is being added to the whole process to integrate security in, making it slower and more expensive to ship software.
  3. Silos between security and development teams add to the challenge of successful integrating security into the development process  

As Brent Midwood puts it perfectly in his article; Security & Development: Better Together

“To be clear, DevOps practices plus security practices does not equal DevSecOps. Rather, DevSecOps is delivery of security as code”

Brent Midwood

The world of software development where a waterfall methodology dominates and isolates teams working in silos is long gone.

Developer-Centric Solutions

Some of the most innovative companies today like Facebook, Google, and Amazon pride themselves in being developer-centric cultures. Developer-centric cultures are more attractive to top engineering talent, one that provides them with mastery, autonomy and purpose is key to building strong engineering cultures. There are several definitions for a Developer-centric culture, but one of the best we heard is

“In a “Dev Centric” culture the developer is responsible throughout the product lifecycle, from product definition to maintaining it in production.”

“In a “Dev Centric” culture the developer is responsible throughout the product lifecycle, from product definition to maintaining it in production.”

Communication of the ACM

At reshift security we believe that the main reason companies don’t really have a grip onr the software security problem, is not the lack of interest by the software developers, but rather the lack of  developer-centric security solutions. 

Looking at our existing software security problem, getting software developers to embrace shipping more secure code it is often seen as a big “change”. 

Developers have adopted and promoted several changes before; “API First ”, “Cloud”, and “Serverless” to list a few. Software developers are a smart breed that solve problems for a living. I see a kiss of death when organizations force the solutions that worked for security audit teams, down onto developers and expect them just to adopt those tools and accept that they work for developers.

How Developer-Centric Security Solutions are Different:

  • Developer tailored education: developers are not security experts, they need documentation built for them and how they consume information. Bridging the knowledge gap within the tool is paramount for developers to succeed with security.
  • Pushing security all the way left: According to research from Google’s attempt to integrate classic static code analysis tools into their SDLC, a survey shows developers’ perception of the issues found depending on when the issues are introduced to them. 74% of the issues flagged at compile time as “real problems,” compared to 21% of those found in checked-in code.
Google_Developers_perception_of_real_issues_in_development

”This result is explained by the "survivor effect"; that is, by the time code is submitted, the errors are likely to have been caught by more expensive means (such as testing and code review). Moving as many checks into the compiler as possible is one proven way to avoid those costs.”

Communications of the ACM
  • High accuracy detection: developers have a very low tolerance for false positives,  their main task is to ship new code, chasing false positives does not appeal to busy developers. Often people will compare security issues to quality issues and try to make the case that they should be treated as quality issues. However, there is a big difference, quality issues usually enter the bug tracking system when there is evidence; i.e. unit tests generated the bug, client reported it or a quality assurance engineer discovered it. Compare that to a tool-generated security issue, with no evidence other than the “tool said so”. So accuracy is obviously very important
  • Automated remediation: finding vulnerabilities is only half the battle, tools that just find issues are seen by developers as more busy work. During Google’s 3rd attempt to integrate regular static code analysis into their process, that particular attempt was focused on submitting the results directly into the code review process as comments, the approach was then stopped as developers saw this to be more of noise than anything else.

Once Google started sending “Fixes” instead of just “Bugs”, developer’s engagement increased dramatically.

"57% of the developers who received a proposed fix to checked-in code were happy to have received it, and 41% were neutral. Only 2% responded negatively, saying, "It just created busywork for me."

Communications of the ACM
Reaction_to_checkedin_code

Seamless integration into developer’s workflow: most security tools do integrate into developers workflow. Some integrations are shallow and other integrations are not. Most security tools offer some integration into the developer’s tools and workflows, perhaps an IDE plugin or some form of integration into the build process. A seamless integration into development is more than IDE plugins and build integrations. Seamless integration into the developer process is one where the developer almost does not feel they are using anything other than their normal tools, yet somehow they are writing more secure code.

Resources

https://cacm.acm.org/magazines/2018/4/226371-lessons-from-building-static-analysis-tools-at-google/fulltext

https://www.secodis.com/owasp-samm-assessment/?lang=en

https://www.darkreading.com/operations/security-and-development-better-together/a/d-id/1329016

https://www.opensamm.org/

 

Why Classic (Gen 1) Static Analysis Security Tools Do not Work Today

vulnerability scanner

Why Generation 1 Security Tools do not Work Today

The truth is that there is no lack of security tools in the market, the list of the static code analysis tools on Wikipedia contains several dozens of tools. However, according to a survey done by GitLab in 2019, 70% of developers don’t believe that they have the tools they need to build secure software. 

How is it possible that there are a lot of security tools that exist in the market but developers don’t find them helpful in securing their code? There are four factors that lead to this paradox.

The User

The existing tools were created mostly between 2002 and 2010, the main user for security tools at this time was the security engineer, primarily in a central security team in an enterprise. The success of these tools with the user profile of a security engineer in an enterprise setting does not mean that these tools would also work for a developer working in an agile development team.

The false positives

Classic static code analysis tools are known for false positives. While it is an annoyance, it is not a deal breaker for the security engineer. For developers, it is pretty much a deal breaker. The security engineer’s job is to do security work. They would rather over analyze than under analyze to prevent security issues from making it to production and they are usually the last line of defense for the application before going to production. For the developers, their job is not to do security work but to write new code, they are the first line of defense and definitely not the last, so too many false positives would prevent them from doing their primary task – writing new code. 

Check out our article Reducing the Risk: A Software Engineering Problem, to read more on this.

The Integration

Since these tools were created primarily for central security teams, integration into the software development tools and processes was not a priority. A lot of these tools added some integration into development tools after the fact, such as offering IDE plugins. These plugins are not really tightly integrated into development workflows but rather a bridge to pull developers from the development world back into the security world, something that developers are not really interested in doing.

The Goals

The security team’s goal is to find as many vulnerabilities as possible in a particular application, in addition to code coverage; how many applications and how much of each application were audited by the team before going to production. Development team’s goals and KPIs are different, development team’s are mostly measured by how many features are pushed to production, and how fast these features are pushed to production. As far as vulnerabilities, how many were found and fixed and fast are these vulnerabilities fixed. Generation 1 tools were designed to help security engineers reach their goals but not necessarily for developers to reach their goals.

Want to check your projects for free?

Insecure Deserialization Primer for Java Developers

jsp-include

Serialization is the processing of converting an object, within a computer program to some form of permanent storage, into a stream or onto the network. Deserialization is the opposite of serialization, transforming the serialized data from storage or network to a program object. The ability to exploit insecure deserialization is to abuse data from a serialized source into an application. The application uses the untrusted data, without sanitizing it, and ingest that data into the application program. The abuse could lead to the execution of software code, authentication bypass, and denial of service.

Impact of Insecure Deserialization

Insecure deserialization occurs when the application deserializes untrusted data without proper validation. Insecure deserialization can lead to remote code execution or denial of service attacks.

Examples of Insecure Deserialization in Java

Deserialization vulnerability in Chatopera v3.10.0
An attacker can execute commands during server-side deserialization by uploading maliciously constructed files. This is related to the TemplateController.java impsave method and the MainUtils toObject method.
GitHub Issue: Chatopera

Remote Code Execution within FastXML
Jackson default type issue allowing for remote code execution
RCE via Deserialization within FastXML

Fixes for Insecure Deserialization

Review the OWASP Cheatsheet for Object Deserialization, go through the checklist and implement if applicable.

In general:

  • Try, at best, to not allow serialization of objects from untrusted sources (possibly unavoidable)
  • Serialization process should be encrypted
  • Deserialize in a limited scope and permissions context
  • Add monitors to potentially long-running deserialization processes
  • Validate user input if possible

Want to check your projects for free?

References

CWE-502: Deserialization of Untrusted Data
GitHub SerialKiller Library: SerialKiller is an easy-to-use look-ahead Java deserialization library to secure application from untrusted input
Github GrrDog Repository: Java Deserialization Cheat Sheet
OWASP: Deserialization Cheat Sheet

Reducing The Risk: A software Engineering Problem

security risk

The best way to solve the software security risk problem is when and where it starts, right at the software creation or as close to the beginning as possible. Solving the problem after the software is written, tested and deployed is like testing and fixing cars after they left the car manufacturing facility. Fortunately, the industry hasalready realized this and started integrating security controls and checks early on in the software development lifecycle.

Shift Left – Developer Centric 

Shift security left is a practice that is intended to find and fix security issues early in the software development lifecycle. The first few iterations of this practice were a Waterfall-ish. For example, OWASP’s version of pushing security left and adding security earlier into the software development lifecycle is OpenSAMM (https://www.opensamm.org/).

OpenSAMM defines 12 security practices divided among 4 business functions. You can see right away how the model makes the assumption that the business functions are nicely segregated from each other. OpenSAMM would work great for organizations that are working using Waterfall methodologies. For Agile development teams, particularly with DevOps practices this would be challenging to implement.

Developer-Centric Solutions

At reshift security we believe that the main reason companies don’t really have a grip over the software security problem, is not the lack of interest by the software developers as many would believe. We believe that the lack of  developer-centric solutions is the main problem. If you look at the software security problem and getting developers to embrace shipping more secure code as a “change”. Developers adopted and promoted several changes before: “API First”, “Cloud”, “Serverless” to list a few. Software developers are a smart breed that solves problems for a living. I see a kiss of death when organizations force the solutions that worked for security audit teams, down onto developers and expect them just to adopt those tools and accept these tools to work for developers.

How Developer-Centric Solutions are Different:
  • Properly shifting security left: shifting security left means integrating security practices early on in the software development lifecycle. According to a research done after Google’s attempt to integrate classic static code analysis tools into their SDLC, a survey has been on the developer’s perception of the issues found depending on when the issues are introduced to them. 74% of the issues flagged at compile time as “real problems,” compared to 21% of those found in checked-in code. 
  • Seamless integration into developer’s workflow: most security tools do integrate into developers workflow. Some integrations are shallow and some other integrations are not. Most security tools offer some integration into the developer’s tools and workflows, perhaps a IDE plugin or some form of integration into the build process. A seamless integration into the development is more than IDE plugins and build integrations. Seamless integration into the developer process is one where the developer almost does not feel they are using a different than what they are normally using but somehow they are writing more secure code. 
  • Developer features: speed, accuracy and usability are features that security tools are not really great at. 

Speed: as discussed before, the speed of software development has gone from months to hours and sometimes minutes. If security is going to prevent the developer from maintaining this speed, it is probably going to be rejected by them.

Accuracy: developers have very low tolerance to false positives. While security engineers look at findings as potential issues, developers look at them as noise. 

Usability: developers appreciate smart and usable tools, because of their craft they come across a lot of tools and usability best practices. 

Ready to get started?

reshift is a light-weight code security tool built for developers to code securely, fix quickly, and deploy fast.

Padding Oracle Primer for Java Developers

padding oracle

The Padding Oracle attack is associated with Modern Symmetric(single key to encrypt/decrypt) Cryptographic systems that use a block cipher. Block ciphers work on encrypting fixed length group of bits called blocks. To enhance security, block ciphers have added modes of operation which support the repeated operation of the cipher across several blocks. Since the original plaintext is never of a fixed length modes of operation employ padding algorithms to ensure all blocks have the same size. The attack relates to the implementation of the Cipher-Block Chaining(CBC) mode of operation and a commonly used PKCS#7 padding scheme and how implementations respond during validation. By iteratively supplying stolen ciphertext concatenated with carefully chosen ciphertext an attacker can work their way towards determining the original data based on receiving padding error or success message.

padding oracle

Impact

A Web Application or target vulnerable to Padding Oracle attacks ultimately exposes the confidentiality of their sensitive data. This may lead to account compromise, exposure of sensitive information, and potentially server compromise. A motivated attacker with patience and tools can decrypt sensitive data. Depending on the nature and sensitivity of the data this might lead to account compromise, leakage of sensitive information, and eventually server compromise.

Testing for Padding Oracle in Java

The testing goal for the attack is to determines if the target is vulnerable and not to attempt to decrypt the ciphertext. The broad strokes of this test can be summarized as:

  1. Determine that there is encrypted content traveling to the target.
  2. Determine that the target emits validation messages.
  3. Confirm that those validation messages occur on a variety of errors.

Since establishing that the target is leaking validation information is fundamental to the vulnerability the tester has to pay very close attention to the response of the server. This may go beyond error messages and include timing responses.

Steps:

  1. Recognize that input is encrypted. This is non trivial as some data in transit may be encoded (base64 for example). This requires potentially decoding the data and careful inspection to see if the data “appears” random.
  2. Recognize blocks. If what you suspect is random data always appears as a combination of blocks (8 or 16) change the first block to all 0s, encode (if necessary), and resend being careful to notice if there are any changes in server behaviour, error messages, or timing. Keep incrementing (and encoding if necessary) the first block while watching server response.
  3. Padding. As this incrementing continues eventually a request will be submitted with the wrong cipher value but the correct number of blocks. This should, if the target is vulnerable, produce a cipher error but not a padding error.

If the target fluctuates in error messages during this sequence then it is vulnerable to a Padding Oracle Attack.

There are also tools available: POET: Padding Oracle Exploit Tool
or PadBuster:Automated Padding Oracle Attacks with PadBuster

Java Fixes

Initialized ciphers of CBC PKCS5Padding as outlined below,

Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);

Must be changed to,

Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);

Tales

ThreatPost: Padding Oracle Crypto Attack Affect Millions of ASP.NET apps

Security researchers have developed an attack against the mechanism that ASP.NET web applications handle encrypted session cookies. The vulnerability could enable attackers to hijack online sessions.

Want to check your projects for free?

References

Wikipedia: Padding Oracle Attack
Robert Heaton Blog: The Padding Oracle Attack
Crypto.StackExchange: How Does Padding Oracle Attack Work?
GitHub Luchob Repository: Padding Oracle Attack Demo
OWASP: Testing for Padding Oracle (OTG-CRYPST-002)
InfoSecInstitute: Padding Oracle Attack explanation
Troy Hunt: Fear, uncertainty and the padding oracle exploit in ASP.NET

JSP XSLT Primer for Java Developers

jsp xslt

JSP XSLT 

Extensible Stylesheet Language Transformations (XSLT) is a transformation language that ingests an XML document and transforms that document into another XML document. If an attacker can control the content of the style sheet, he/she would potentially be able to trigger remote code execution (RCE) or server-side path traversal.

Fixes for JSP XSLT

Take for example a simple XSLT transform,

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/technology_companies">
	<xsl:value-of select="system-property('xsl:vendor')"/>
  </xsl:template>
</xsl:stylesheet>

In this example the logic injects value matching /technology_companies, this could be a potential area to inject code. If an attacker were to be able to inject directives, they could discover the XSLT library being used and exploit further, e.g. system-property('xsl:vendor')

A general solution if XSLT is required to be used:

  • Avoid interpreting user defined XSLT documents
  • Do not generate XSLT documents and internal fields from inputs that can be controlled by the user, e.g. company name
  • Based upon the XSLT library in use, review the library’s default settings and disable unsafe functionality that could lead to XML External Entities from being executed

Want to check your projects for free?

References

WS-Attack: XML Signature – XSLT Code Execution
ContextIS: XSLT Server Side Injection Attacks
OWASP: Path Traversal

JSP JSTL Out Primer for Java Developers

Java Server Pages(JSP) currently can define tag definitions through the Standard Tag Library (JSTL). One of the tag functions is the ability to disable escapeXml which could potentially be dangerous in Cross-Site Scripting attacks. By disabling escapeXml an attacker can manipulate an XML document which is reflected within a client browser and inject HTML and/or Javascript syntax.

Impact of JSP JSTL Out

Exploiting the Standard Tag Library leading to a successful Cross Site Scripting (XSS) attack results in javascript code running in a users browser without their knowledge. That code then reads the session cookie of a logged in session to their bank, work account, or any other account they have a session with. Once in possession of the session cookie, the malicious code then transmits that value to the attacker who can then connect to the site with that session cookie assuming the role of the original user. Now the attacker can do anything as that user.

Fixes for JSP JSTL Out

All data elements rendered within response content must be properly encoded to ensure the data is not interpreted as markup code by the user’s web browser. Depending on where within the response the data is rendered, one of the following encoding methods should be used: HTML: HtmlEncoding should be used to escape all rendered output. For example, script tags are escaped by replacing the < and > characters with < and >. JavaScript: Data rendered within JavaScript code can be encoded into the format \xDD where DD is the hexadecimal value of the ASCII character. This causes the encoded characters to be taken literally by the browser, rather than interpreted as meta characters. URL: Data rendered within a URL should be URLEncoded into the format %DD, where DD is the hexadecimal value of the ASCII character. HTML Attributes: Properly quoted attributes can only be escaped with the corresponding quote. Ensure that the attribute is quoted and that any quotes within the data value are encoded. Most development platforms have a native encoding mechanism that can be leveraged to perform the above encodings. Additionally, there are a number of publicly available APIs that provide encoding functionality.

Specifically,

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<c:out value="${param.test_param}" escapeXml="false"/>

must be changed to,

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<c:out value="${param.test_param}"/>

Want to check your projects for free?

References

CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)
Tutorial Point: JSTL fn:escapeXml definition
Oracle: JSTL core Tag out

JSP Spring Eval Primer for Java Developers

JSP Spring Eval
Spring can specify functionality within a Java Server Page(JSP) to inject into the eval tag an expression to be executed at render time. If the expression can be wholly or partially control by user input, an attacker could inject dynamic values to inject code to be executed when the page is rendered on the server.

Impact of JSP Spring Eval

Method invocation and arbitrary code execution can occur within the context of the application allowing for sensitive data exposure, system access and even the risk of the entire server being compromised.

Fixes for JSP Spring Eval

The source of the value(s) should be verified to avoid unfiltered values falling into this risky code evaluation

<%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
<spring:eval expression="${param.lang}" var="lang" />
...
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
<spring:eval expression="'${param.lang}'=='fr'" var="languageIsFrench" />

must be changed to,

<c:set var="lang" value="${param.lang}"/>
<c:set var="languageIsFrench" value="${param.lang == 'fr'}"/>

Want to check your projects for free?

References

CWE-94: Improper Control of Generation of Code (‘Code Injection’)
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code (‘Eval Injection’)
Spring Documentation: Class EvalTag

Insecure Data Storage Primer for Java Developers

insecure data storage

Insecure data storage is when files can be identified and contain plain text or encoded credentials. These credentials include usernames, passwords, private encryption keys, and other potentially sensitive data that can be leveraged to obtain unauthorized application access. Depending on the nature of the embedded data, these secrets can be used to obtain access to various application resources, such as back-end database servers and/or administrative functionality.

Fixes for Insecure Data Storage

Remove all instances of plaintext or encoded credentials from within all files. Developers and administrators should always work with the assumption that a malicious attacker is likely to obtain access to application source code (via source code disclosure vulnerability, de-compilation, etc) or other files and scripts used for administration purposes. This assumption is especially critical when considering code that is deployed on externally accessible systems (resources located in web accessible directories, client-side code, etc). Usernames and passwords stored for access to other systems must always be encrypted when stored and should only be decrypted on-the-fly as needed by applications or other systems. Consider encrypting sensitive personally identifiable information, such as social security numbers, to help protect it in the event of unauthorized access to the storage medium.

Want to check your projects for free?

References

CWE-922: Insecure Storage of Sensitive Information
SE Works: Understanding Insecure Data Storage & How To Approach It
OWASP Mobile Top 10: Exploring Insecure Mobile Data Storage

Insecure Crypto Primer for Java Developers

insecure cryptography

Insecure Cryptography is a general vulnerability in which the encryption algorithm chosen for use cases such as authentication, integrity checks, signature verification is weak and susceptible to attacks. Typical attacks exploit the algorithms collision characteristics, i.e. the ability of the attacker to control/predict what the algorithm produces for two different data inputs. If an attacker was able to identify a collision of two inputs that produce the same output, they would be able to identify the original text.

Impact of Insecure Cryptography

If an attacker can exploit a poorly chosen encryption algorithm, this may allow for an attacker to decrypt the text and violate data confidentiality and/or message integrity.

Fixes for Insecure Cryptography

Reconfigure the service to use a strong encryption algorithm along with key lengths that provide a minimum of 112-bits of effective key strength.


Examples of industry-tested and accepted standards and algorithms include AES (128 bits and higher), RSA (2048 bits and higher), ECC (224 bits and higher), and DSA/D-H (2048/224 bits and higher).

Want to check your projects for free?

References

CWE-310: Consolidation of Cryptographic Issues
Shattered.IO: How We Broke SHA-1 in Practice
Stack Exchange: What Cryptographic Algorithms Are Not Considered Secure