A version of this article appeared in SC Magazine. It has been modified and syndicated here.


If you’ve ever had your home broken into by thieves, you’ll understand that initial sinking feeling that something is wrong, followed by the realization that you have, indeed, been stolen from and violated. It usually results in lasting discomfort, not to mention a pivot to security measures that would rival Fort Knox.

Now imagine your home is breached, because the thieves have made themselves a key. They creep around, coming and going as they please, but are careful to remain undetected. Then, one day, you notice all too late that the jewelry you hid in the freezer is gone, your safe has been emptied, and your personal belongings have been ransacked. This is the equivalent reality an organization faces if it falls victim to a zero-day cyberattack. In 2020, a study by the Ponemon Institute revealed that 80% of successful data breaches were the result of zero-day exploits, and sadly, most companies remain ill-equipped to make a significant improvement on this statistic.

Zero-day attacks, by definition, give developers zero time to find and patch existing vulnerabilities that could be exploited, because the threat actor got in first. The damage is done and then it’s a mad scramble to fix both the software and reputational damage to the business. Attackers are always at an advantage, and closing that edge as much as possible is crucial. 

The holiday gift nobody wanted - Log4Shell - is currently blowing up the internet, with over a billion devices said to be affected by this catastrophic Java vulnerability. It’s shaping up to be the worst 0day attack on record, and we’re just getting started. Despite some reports stating that exploits started a few days before public disclosure, a presentation given at Black Hat Conference in 2016 would suggest this has been a known issue for some time. Ouch. Worse still, it’s painfully easy to exploit, and every script kiddie and threat actor on the planet is chasing paydirt with this vulnerability. 

So, what is the best path forward for defending against a slippery, sinister threat, not to mention vulnerabilities that have been missed in the software development process? Let’s take a look. 

Zero-day attacks against big targets are rare (and expensive)

There’s a huge market for exploits on the dark web, and zero-days tend to go for a pretty penny, with one example in this article listed for $2.5M at the time of writing. Reported to be an exploit of Apple iOS, it’s no surprise that the security researcher’s asking price is through the roof; after all, this could indeed be the gateway to compromise millions of devices, harvest billions of sensitive data records, and do it as long as possible before it’s discovered and patched.

But who has that kind of money, anyway? Typically, organized cybercrime syndicates will come up with the cash if it’s deemed worthy, especially for ever-popular ransomware attacks. However, global governments and defense departments are among the clientele for exploits they can use for threat intelligence, and in more positive scenarios, the companies themselves may be buyers of their own potential zero-day exploits so they can mitigate disaster. 

2021 saw records broken for live zero-day exploit discoveries, and it is large organizations, government departments, and infrastructure that are most at risk of being probed for any weaknesses. There is no way to be completely safe from the possibility of a zero-day attack, but you can “play the game” somewhat by offering a generous and well-structured bug bounty program. Rather than wait until someone offers the keys to your software castle on a dark web marketplace, get legit security buffs on your side and offer them decent rewards for ethical disclosure and potential fixes. 

And if it just so happens to be a hair-raising zero-day threat, it’s safe to assume you’ll need to cough up more than an Amazon gift card (and it will be worth your while to do so).

Your tooling could be a liability for your security personnel

Cumbersome security tooling has been an issue for a long time, with the average CISO managing anywhere from 55 to 75 tools in their security arsenal. Aside from being the world’s most confusing (metaphorical) Swiss Army Knife, 53% of enterprises aren’t even confident they’re working effectively, according to a study by the Ponemon Institute. Another study revealed that just 17% of CISOs thought their security stack was “completely effective”.

In a field known for its burnout, lack of security-skilled people to meet demand, and need for agility, forcing security professionals to work with information overload in the form of data, reporting, and monitoring of huge toolsets is burdensome. This is exactly the type of scenario that can cause them to miss a critical alert, which may well have been the case when it came to properly assessing Log4j for its weaknesses. 

Preventative security should include developer-driven threat modeling

Code-level vulnerabilities are often introduced by developers, and they need precision guidance and regular learning pathways to build secure coding skills. However, next-level secure developers have been given the opportunity to learn and practice threat modeling as part of their software creation process.
‍
It shouldn’t come as a surprise that the people who know their software best are the developers who have sat there and created it. They have powerful knowledge on how users interact with it, where the features are used, and when sufficiently security-aware, potential scenarios where it could break or be exploited. 

If we bring this back to the Log4Shell exploit, we are unfortunately seeing a scenario where a catastrophic vulnerability has escaped detection by experts and complex toolsets, however, it may not have occurred at all if the library was configured to sanitize user input. The decision against doing so seems to have been an obscure feature for added convenience, but made it painfully easy to exploit (think SQL injection-level, certainly not genius stuff). If threat modeling was done by a group of keen, security-savvy developers, it’s highly likely this scenario would have been theorized and considered.

A great security program has an emotional component, with human intervention and nuance at the heart of solving human-created issues. Threat modeling takes empathy and experience to be effective, as does secure coding and configuration at the architectural level of software and applications. This is not something that developers should be thrown into overnight, but a clear pathway to upskill them to a level where they can take the pressure off the security team for this important task is ideal (and it’s a great way to build rapport between both teams). 

Zero-days lead to n-days

The next part of dealing with a zero-day is getting patches out as fast as possible, hoping like hell that every user of the vulnerable software applies it as soon as possible, and certainly before an attacker gets there first. With Log4Shell, it could eclipse Heartbleed in its endurance and potency in the face of it being embedded in millions of devices, and creating complex dependencies across a software build.

Realistically, there is no way to completely stop this type of insidious attack. However, with a commitment to using every avenue to create quality, secure software, and approaching development with the same mindset as you would critical infrastructure, we can all have a fighting chance.

Developers create and test their own code with various methods. One such method is unit testing - a very popular method of testing the smallest parts of one’s own code. When written well, unit tests can help to improve the quality of your code, as well as reduce costs and development time. Whether done as part of test-driven development (TDD) or not, unit testing is a key part of modern development practices and its importance has led to the creation of many testing frameworks.

But in the absence of a proper testing framework and guidance, unit tests can become complex and unreadable as the focus shifts to coverage and quantity rather than quality and readability. This is especially true in a large and active codebase with many unit tests.

A good test framework helps create good readable tests that are simple and focus on quality testing. They also help document the way to use your code as well. One such framework is AssertJ.

AssertJ is a fluent API for writing unit tests in Java. It lets you write test assertions that read like English, with context-aware autocomplete. If you have a large number of tests and need to improve their readability, you may wish to migrate all of them to AssertJ and also ensure that all future tests are taking full advantage of AssertJ.

But complete migration can take an enormous effort and time to do manually and so it is often skipped or put off for other development tasks. So we created Sensei - a highly customizable IntelliJ plugin that can help migrate your current unit tests to use AssertJ as well as enable all future tests to be written the right way. This is done with a number of recipes (rules) already created for you by Sensei’s development team. Sensei makes it easy to perform a one-time migration or take the approach of doing incremental migrations to AssertJ, one test at a time. Once you have moved to AssertJ, the recipes continue to help developers apply quick fixes as they write unit tests so that your unit tests continue to be uniform, standard and consistent across the entire codebase.

‍

About Sensei

Sensei is a highly customizable IntelliJ 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.

Here is an example of a sample migration that might help you see how Sensei makes it painless to migrate your unit tests to use AssertJ.

Why is AssertJ a great framework to write unit tests

Instead of writing a test like this JUnit assertion:

you can write this with AssertJ:

This means you can read the assertion left to right like an English sentence, and it’s clear which is the expectation (in this case, the size 3). How many times have you written an assertion the wrong way around, like this?

These are just simple examples. The more complex your checks and assertions, the more AssertJ helps you make your tests simple and readable. It works nicely with your IDE’s auto-complete. As soon as you type:

it will pop up with all the things you can check, based on the type of myResult. If it is a collection, you can check its contents, size, whether it contains certain values or types, and so on.

Out of the box, AssertJ has support for primitives and their boxed types, Atomic types, Collections, arrays, Maps, Dates, java.time, Futures, Files/Paths, InputStreams, Throwables, and URLs. And if you have a favorite custom Matcher for Hamcrest, you can use it with AssertJ via HamcrestCondition.

Readable unit tests make it easy for developers to read code in normal English and therefore make it easy to spot mistakes as well as increase coverage - which makes AssertJ an indispensable framework for good Java unit tests.

Recipes to move legacy unit tests to AssertJ

We have written a cookbook to help you write consistent code with AssertJ. It can help you migrate your assertions to AssertJ from any of these frameworks: JUnit 3, JUnit 4, JUnit 5 and FEST-Assert.

This cookbook can be configured in Sensei for immediate use and you can find installation instructions for Sensei here.

Write better unit tests as you code - improving JUnit quality progressively

The Sensei cookbook for AssertJ doesn’t just help you to migrate from other frameworks. It has some recipes which can help you to improve your test writing, break old habits, and write more idiomatic AssertJ tests.

For instance, let’s say you have written a test which looks like this:

Perhaps you even migrated it using one of the migration recipes above, from this JUnit-style assertion:

The Sensei cookbook for AssertJ has a recipe that can also detect this old style of assertion, and offer to convert it to this:

Another recipe can convert the following from:

to this:

A one-time migration and uniform coding practices across teams - with Sensei

We can see from our examples above, the manual migration of unit tests to use AssertJ can involve a lot of effort and time that is best spent on writing better tests. By using Sensei, you can easily migrate your unit tests to AssertJ with confidence. You can perform a one-time migration, or migrate individual tests to AssertJ as you come across them. Sensei provides this type of flexibility that makes code migrations less painful.

Unit test migration is just one example of the many ways Sensei can be used to write consistent code across 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.

If you have any questions, we’d love to hear from you! Join us on Slack at: sensei-scw.slack.com

Migrating code (read: legacy code) is not fun. It takes an enormous amount of planning and effort to get it across the line. While not the most exciting or motivating piece of work for developers, it does require determination and the right experience to migrate legacy code to new library versions. Joda-Time to java.time is one such migration that requires meticulous planning and execution.

If your Java project started its life out prior to Java SE 8, and uses date/time processing, then it probably used Joda-Time - an excellent library and a de-facto standard to handle date and time functions prior to SE 8. If your project still uses Joda-Time but would like to migrate to java.time then read on.

The release of Java SE 8 included a new and improved standard Date and Time API commonly referred to as java.time (JSR-310). The Joda-Time project now recommends migrating to java.time (JSR-310).

While java.time (JSR-310) was heavily inspired by Joda-Time, it is not backwards compatible and concepts and terminologies have changed. Thats why migrating from Joda-Time to java.time requires careful attention on each and every line of code that you change. This can be time-consuming and would almost make you wish there was an easier and automated way to migrate.

There is a better way to migrate and we’ve created it using Sensei - an IntelliJ plugin to automatically perform code transformations as per the recipes (rules) defined by you. Spend your time defining reusable recipes, rather than performing repetitive migration tasks. The automation will not not only transform your legacy Joda-Time code, but also help teams follow the guidelines right there in the IDE as they write new code.

To help you get a head start, we have created a public Sensei cookbook Standardization on java.time (JSR-310) which includes recipes to migrate from Joda-Time to java.time in a less painful way. This is a growing set of recipes that we will continue to expand to add more coverage with more recipes.

Here is an example of a sample migration that might help you see how Sensei makes it painless to migrate legacy code.

From repetitive manual migration to automated code transformations

Let’s look at an example of creating a new DateTime which demonstrates a few hidden traps when migrating a single line of code from Joda-Time to java.time. We will then look at one of our Sensei recipes from our Standardization on java.time (JSR-310) cookbook and show how it captures all this information, so that this same migration can be re-used again and again by any developer.

In this example, we are constructing a Joda-Time DateTime from 7 int arguments representing values of the DateTime fields.

How do we migrate this to a java.time equivalent?

The javadoc in Joda-Time for this constructor says:

Constructs an instance from datetime field values using ISOChronology in the default time zone.

At first, we might assume there is DateTime class in java.time, but there isn’t one. If you google ‘migrate from joda time to java time’ you will most likely find Stephen Colebourne’s blog post Converting from Joda-Time to java.time.

This gives you a good start, and points us in the direction of using java.time.ZonedDateTime or java.time.OffsetDateTime. Here is our first question, which one do I use? Probably ZonedDateTime based on Stephen’s comments.

Looking up the ZonedDateTime javadoc, we can’t see any constructors at all. Returning to Stephen’s blog post we read further down:

‍Construction. Joda-Time has a constructor that accepts an Object and performs type conversion. java.time only has factory methods, so conversion is a user problem, although a parse() method is provided for strings.

So there must be a static factory method, searching the static methods we find one that looks pretty close, but it’s not exactly the same.

It has 7 int parameters like our original Joda-Time DateTime constructor, however if you don’t pay attention you will miss an important detail.  The 7th parameter no longer represents milliseconds, it expects nanoseconds instead, this is because java.time has increased precision over Joda-Time and measures instants to the nano-second. An important detail that you could have easily missed. Additionally, this method expects a ZoneId, so it makes you wonder as to why you didn’t need one before and why do you need it now.

Remembering the javadoc of our original constructor which mentioned it would use the default time zone, maybe there is a way to get the default ZoneId?

The javadoc for ZoneId does not tell us about any constructors listed, but looking at the static methods we see we can use systemDefault()

Now that we have sorted out the ZoneId, what should we do about our milliseconds to nanoSeconds conversion? Maybe we can use java.util.concurrent.TimeUnit to perform the conversion.

This method returns a long, and our method expects an int, so now we have a conversion problem to solve as well. Maybe we could try something simple. A multiplication?

This will work but does look a little out of place. If you haven’t noticed already, we have spent a considerable amount of time and effort to migrate a single line of code. But as you can imagine, we have many such edits to do by hand and it does not get better.

However, if we were to look a little harder at java.time API, we can discover a solution that looks a little bit more fluent.

Although ZonedDateTime has no obvious way to set the Milliseconds, it can be done using the with(TemporalField field, long newValue) method, using ChronoField.MILLI_OF_SECOND as the TemporalField.

And the java doc mentions that it will perform the Conversion to Nanoseconds for us:

When this field is used for setting a value, it should behave in the same way as setting NANO_OF_SECOND with the value multiplied by 1,000,000.

So we can simply specify 0 for our nanoseconds in the factory method, and then use the with method to create a ZonedDateTime that has all the original values as well as the milliseconds.

Looking at our final result, it looks like we have only changed a single line of code, it doesn’t really show the effort that went researching just one migration!

‍

Create a recipe to migrate faster and easily

Sensei provides a way for us to share this hard-won information with other developers. By creating a recipe that captures all these requirements, it will allow Sensei users to perform this migration with the click of a mouse.

A Sensei recipe consists of 3 main sections:

• Metadata
• Search
• AvailableFixes

Let us look at a Sensei recipe (can also be viewed as a YAML recipe) that will help us migrate this call into its java.time equivalent.

DateTime foo = new DateTime(year, monthOfYear, dayOfMonth, hourOfDay, minuteOfHour, secondOfMinute, millisOfSecond);

Metadata Section

The metadata section contains information about the recipe and how it should be used.

Search Section

The search section of a Sensei recipe specifies what code elements this recipe should apply to.

search:
 instanceCreation:
   args:
     1:
       type: int
     2:
       type: int
     3:
       type: int
     4:
       type: int
     5:
       type: int
     6:
       type: int
     7:
       type: int
   argCount: 7
   type: org.joda.time.DateTime

‍

In this search section we see that we are:

• Searching for an instanceCreation, i.e. a usage of a Constructor. Note: there are many other search targets available
• The constructor should have 7 arguments, this is specified by the argCount property
• args 1-7 should be of type int
• We are searching for constructors of the type org.joda.time.DateTime

‍

Available Fixes Section

The availableFixes section can specify one or more fixes that can be applied to the matching code element. Each fix can have multiple actions, and in our case we have a single fix, that performs 2 actions.

‍

• The name of the fix is shown to the user in the ‘Quickfixes’ menu, and describes what will happen if the user applies this quickfix
• The actions list shows what actions will be performed by this quickfix
• The rewrite action will rewrite the code element using a mustache template. It can make use of variables and string replacement functions.
• The modifyAssignedVariable action will check to see if this constructor is being used to assign the value to a variable. If so, this action will modify the variable to be declared as the type specified by type

‍

Using the recipe to do code transformation

With our recipe is written and enabled, it scans our code and highlights the segments to which it can be applied.

In the screenshot below we can see the target constructor has been marked by Sensei. Hovering over the marked constructor shows us the Recipe shortDescription and the Quickfix option Migrate to java.time.ZonedDateTime

‍

After we select the Migrate to java.time.ZonedDateTime quickfix, the code is transformed according to the actions we specified in the recipe.

‍

A one-time migration and uniform coding practices across teams - with Sensei

We can see from our example above, the migration of a single line of code can involve hard-won knowledge. Sensei can turn that knowledge into actionable recipes or cookbooks that can be shared within teams. You may plan a one-time migration sprint or take the approach of doing incremental instant transformations to java.time as and when you come across Joda-Time code. You can enable/disable recipes as a way to do migrations in logical stages or steps and even, expand or reduce the scope of the files scanned by Sensei - the flexibility that makes code migrations less painful.

Library migration 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.

If you have any questions, we’d love to hear from you! Join us on Slack at: sensei-scw.slack.com

Chances are if you deal with software in any way, whether you’re a developer, QA, an Engineering Lead, or an AppSec professional, security is part of your job. It’s the security team’s job to point out software vulnerabilities, and it’s the developer’s job to do their best to write code without flaws to begin with. But in order to do those jobs as efficiently and effectively as possible, it’s important that all parties work together against security threats, starting with the code your applications run on. 

Effectively learning about secure coding and retaining that knowledge, however, can make it seem like it’s inherently difficult. With the right tools, it doesn’t have to be. But it’s not always easy to convince stakeholders and superiors to invest in the right kind of training. Training is too often chosen with the sole goal of ticking a compliance box and much of the time it’s irrelevant to a developer’s daily work. But what if developers could learn about security in real-time, in the language:framework they work in everyday, and have fun doing it? And to top it all off? Your organization complies with industry standards at the same time.

We’ve got your back. Here are some strategies to gain allegiance from your peers, leads, and ultimate decision-makers within your organization to get on board with a developer-focused security coding training program.   

Avoiding software vulnerabilities from the start saves immeasurable amounts of time and money

Do you find yourself spending too much of your time either finding, reporting, or fixing repeat security issues? You’re not alone. 

Imagine the following scenario: As soon as AppSec finds a vulnerability and reports it back to development, developers then hop into a relevant training lesson and learn not only how to fix that flaw, but how to avoid making the same mistake in the future. What do you think the result would be? That developer would most likely remember that lesson due to its relevance and be less likely to make the same error again. This means that if you work on a security team, that’s one developer less likely to unknowingly create that vulnerability again and that same developer is less likely to have to go back and fix it again.

Check out this video from our customer, Contrast Security, on how powerful real-time training is for their development team.

If all developers took part in regular secure code training and had the tools at their fingertips to learn about security issues in real-time, the time that is regained to create amazing software and work on security programs is immeasurable. Sound like a pretty good argument for your organization to invest in a tool just like that, right? 

If you’ve found a great tool you’d love to use to skill-up in security, something like (cough) Secure Code Warrior, this is a great argument for pitching it to the CISO or CTO within your organization. 

Empowered developers deliver better results and they’re happier

Time and money are of course very important to your management team, but so is your job satisfaction. Satisfied employees deliver better results, stay longer at their jobs, and contribute to a positive work environment. That’s why career building and training is an investment, not a cost. And if that training is actually fun and teaches something relevant? That’s a golden ticket to success right there. 

The great news is that developers are typically highly motivated to learn security because they know how important it is for their jobs. We surveyed developers from all over the world in a study with Evans Data Corporation and found out that developers want to learn security because: 

1. It increases productivity and efficiency
2. They’re curious and personally interested in learning about it
3. They want to avoid the problems associated with insecure code
4. They understand it provides the potential for career advancement
5. It’s a more efficient use of human resources
   

(Download the full whitepaper here.)

The only problem is that most secure coding training is letting them down. It’s not relevant to their daily work and, let’s face it, it’s downright boring. Those are features that don’t usually deliver good results in terms of retaining information and actually learning. When the learning platform is developer-centric, fun and engaging, and relevant to their work, however, it can deliver real results and create empowered individuals who want to write secure code. And why would your boss, be it a development lead or a CISO or CTO not want developers to be interested in coding securely and have the skills to do so?

Security understanding makes overall better engineers 

When engineers understand how software can be vulnerable to attacks, then they do their work with that in mind. The more someone understands what can go wrong, the more they work with a preventative approach.

Not only that, but poor quality code is more likely to contain software vulnerabilities and it’s easier for a developer to unknowingly introduce a vulnerability into that code. Why? Because a lot of what they do is read and alter code. When that code is poorly organized and uses poor logic, it takes longer to perform those tasks and it becomes easier to change something and accidentally introduce a critical security bug.

When there's an understanding of security and how to avoid problems, you also think harder about the overall quality of that code and how to write it in such a way that a bug can’t easily be introduced on accident. Security training is a win-win. Developers learn about secure coding, but they also become better engineers in the meantime. 

There’s power in numbers

Another great tactic to get buy-in from your leaders to adopt a secure coding learning platform is to get your colleagues on board. The more developers interested in upskilling their security knowledge, the easier it will be to convince management or the C-suite to invest in it.

So how do you do that? Given the fact that most developers understand the need to get better at security and want to learn, it shouldn’t be too hard. You can also have them take a look at this secure code warrior developer showcase  and get a sneak peek at our product and start testing out their secure coding skills. Once they see the impact of insecure code and learn that learning about security can be fun, they’ll feel empowered to learn more. 

Once you’ve adopted the right tool, a great way to get your developers engaged is with some healthy competition. Try kicking off your training program with a tournament. 

Check out how Nelnet got really creative with tournaments to build a security culture within their company.

Ongoing security training promotes a desirable company culture

Training doesn’t have to be boring, and it really shouldn’t be. We know that lectures are expensive, difficult to organize - especially with distributed teams - and you’re unlikely to take much away from them. But organizations continue to offer secure coding training to developers that does little more than tick a box each year for compliance. It’s no longer enough to simply maintain the status quo. It’s time for development managers and AppSec to step up their game and work together to implement a training tool that promotes ongoing and engaging learning. And that starts with convincing the decision-makers.

Continous, hands-on training is necessary for a number of reasons. Cybersecurity threats are constantly evolving, so it’s only natural that training to combat those threats occurs continuously as well. Not only that, but as mentioned already, when we learn in real-time, we’re much more likely to retain what we learned. Coding with security in mind is hard to implement, because expecting a developer to recall something they learned from a slideshow out of context perhaps almost a year previously is unrealistic. But if they learn how to avoid a particular software vulnerability the moment it’s reported to them and feel like they’re playing a game at the same time, that’s a whole new ballgame. 

As soon as hands-on, relevant training is implemented, security becomes part of the company culture and is no longer treated as an afterthought. It gets baked into the development process from the start of the software development lifecycle. 

So what are you waiting for? Start your journey to improving security within your organization and protecting vital company and customer data. Get your developers and bosses on board to take secure coding to the next level in your organization. Stop experiencing the same vulnerabilities time and again once and for all by thinking about security from the very start. 

Need more resources?‍

Download the full "Convince your CISO / CTO kit"

At the beginning of October, Apache released version 2.4.49 to fix a Path Traversal and Remote Code Execution vulnerability and then subsequently 2.4.50 to address the fact that the fix in 2.4.49 was incomplete. Perhaps you’ve seen talk on social media about the importance of updating to the latest version to avoid these risks, given that Apache powers 25% of the internet by some estimates. But what’s the deal? How much risk exists here?

Why not try it out  yourself? 

We’ve built a mission to demonstrate the risks in a real-life environment and have made it public for everyone to try. In this Mission, we’ll walk you through how the Path Traversal Vulnerability can impact your infrastructure and applications. Click below to jump right in, or continue reading to learn more about the vulnerability in detail.

About the Path Traversal Vulnerability 

The vulnerability was introduced in the 2.4.49 release (due to a change to the URL normalization function), where a new path normalization function was introduced. Unfortunately, it failed to correctly normalize URL encoded paths. This makes it possible to conduct a path traversal attack if the following configuration is not present:

And if mod_cgi is enabled, it can also be leveraged into a Remote Code Execution vulnerability. But let’s first dig into URL encoding to better understand what went wrong. 

URL Encoding

At its most basic, the vulnerability occurs due to a lack of consideration for URLs with URL encoding. The newly introduced path normalization function did not fully handle cases where dots were URL encoded. 

Remember that to conduct a path traversal attack, you will need to traverse with the sequence ../. The normalization function, however, is smart enough to strip that out. So what do you do? You can URL encode a .(Dot) down to %2e, and use a sequence like .%2e/. That would work in many cases against Apache 2.4.40. But you can also go one step further and double encode it. The URL encoded version of .%2e/ is .%252e/. This was further able to bypass the attempted normalization by Apache.

But there's a catch

If someone wanted to try to exploit this vulnerability straight in their browser, they would not be successful. This is due to the fact that browsers also try to normalize URLs that are sent to servers. This means that even our double-encoded sequence will be removed. It also means  that we can't simply use a browser to demonstrate this.

You can use cURL to demonstrate this by using the --path-as-is flag, which prevents it from normalizing the URL before sending it:

Prevention and mitigation

To fully prevent the issue, it's important to keep up to date with the latest patches from Apache. Specifically, you will want to upgrade to 2.4.51 at a minimum. But it's a good practice to upgrade on a regular schedule to stay up to date.

To mitigate against this issue if you are running 2.4.49, ensure that you have included the following in your Apache configuration:

And to prevent Remote Code Execution, disable mod_cgi if you do not utilize it.

Experience the impact for yourself

Interested in exploring exactly what happened and trying it out for yourself? 

‍

Micha Martinez is a Cybersecurity Analyst and Cinematographer at Nelnet, a US conglomerate that deals in the administration and repayment of student loans and education financial services. When he was tasked with creating a training program for developers around secure coding, he took on creative ways to engage his team. We were so impressed with how he runs his secure code training program that we sat down with him to learn more. 

The bottom line? 

Create a culture of security and nurture your internal security champions from within your development teams “to be the force of good.” 

“By focusing on secure code, we’ve helped make the company stronger and safer.” 

At Nelnet, Micha and his security team understood the importance of building secure code from the start. They wanted to achieve this in an engaging, relevant, and rewarding way. He discovered that by identifying developers with a strong interest and proficiency in secure coding and nurturing them to become security champions, those champions became the catalyst for changing the mindset around security training as a whole. These individuals mentor their colleagues who need more help at a peer-to-peer level, and become the leaders in implementing changes in secure code practices within the organization. 

Here’s more from Micha about how he and his team shifted the mindset and culture around security prevention, which made their company “stronger and safer”.

It’s all about the bragging rights… and reducing vulnerabilities

Micha doesn’t run your average security training program. He uses competition and his cinematography talents to make tournaments hugely engaging and successful. What developers gain is highly relevant, practical knowledge that leads to stronger secure code. 

The business wins too as their products become more secure and provide a higher level of protection against software vulnerabilities. Learning software security doesn’t have to be a typical and boring learning experience that does little more than check a box. Developers want training experiences that are immersive and challenging, as well as relevant to their daily work. 

Watch Micha talk about how he makes secure coding training fun through tournaments including physical championship belts a la wrestle mania as the prize. All it takes is a little healthy competition to keep security top of mind for his team. 

Who doesn’t love some bragging rights? 

‍

Embrace a culture centered around secure coding... the tool is not enough

Micha left us with one last thought about why he recommends Secure Code Warrior. The platform was the vehicle that led him to create a preventative culture and proactive learning. It took time to build the training program and also invest in the developers who train and perform well. It takes a transformative culture to build the skills in each developer to adopt a preventative approach to coding securely. 

Here more from Micha about why embracing a culture of secure coding makes all the difference with Secure Code Warrior.

Secure Code Warrior delivers an immersive and engaging secure coding learning platform for developers. Interested in a demo? Book one below. 

In this increasingly chaotic world, there have always been a few constants that people could reliably count on: The sun will rise in the morning and set again at night, Mario will always be cooler than Sonic the Hedgehog, and injection attacks will always occupy the top spot on the Open Web Application Security Project (OWASP) list of the top ten most common and dangerous vulnerabilities that attackers are actively exploiting.

Well, the sun will rise tomorrow, and Mario still has “one-up” on Sonic, but injection attacks have fallen out of the number one spot on the infamous OWASP list, refreshed in 2021. One of the oldest forms of attacks, injection vulnerabilities have been around almost as long as computer networking. The blanket vulnerability is responsible for a wide range of attacks, including everything from traditional SQL injections to exploits launched against Object Graph Navigation Libraries (OGNL). It even includes direct assaults against servers using OS command injection techniques. The versatility of injection vulnerabilities for attackers - not to mention the number of places that could potentially be attacked - has kept this category in the top spot for many years.

But the injection king has fallen. Long live the king. 

Does that mean we’ve finally solved the injection vulnerability problem? Not a chance. It didn’t fall far from its position as security enemy number one, only down to number three on the OWASP list. It would be a mistake to underestimate the continuing dangers of injection attacks, but the fact that another vulnerability category was able to surpass it is significant, because it shows just how widespread the new OWASP top dog actually is, and why developers need to pay close attention to it moving forward.

Perhaps the most interesting thing, however, is that the OWASP Top 10 2021 reflects a significant overhaul, with brand new categories making their debut: Insecure Design, Software and Data Integrity Failures, and an entry based on community survey results: Server-Side Request Forgery. These point to an increasing focus on architectural vulnerabilities, and going beyond surface-level bugs for the benchmark in software security.

Broken access control takes the crown (and reveals a trend)

Broken access control rocketed from the fifth spot on the OWASP top ten vulnerabilities list all the way up to the current number one position. Like with injection and new entries like insecure design, the broken access vulnerability encompasses a wide range of coding flaws, which adds to its dubious popularity as they collectively allow damage on multiple fronts. The category includes any instance where access control policies can be violated so that users can act outside of their intended permissions. 

Some examples of broken access control cited by OWASP in elevating the family of vulnerabilities to the top spot include ones that enable attackers to modify a URL, internal application state, or part of an HTML page. They might also allow users to change their primary access key so that an application, site, or API believes they are someone else, like an administrator with higher privileges. It even includes vulnerabilities where attackers are not restricted from modifying metadata, letting them change things like JSON web tokens, cookies, or access control tokens.

Once exploited, this family of vulnerabilities can be used by attackers to bypass file or object authorizations, enables them to steal data, or even perform destructive administrator-level functions like deleting databases. This makes broken access control critically dangerous in addition to being increasingly common.

It’s quite compelling - yet not surprising - that authentication and access control vulnerabilities are becoming the most fertile ground for attackers to exploit. Verizon’s latest Data Breach Investigations Report reveals that access control issues are prevalent in almost every industry, especially IT and healthcare, and a whopping 85% of all breaches involved a human element. Now, “human element” covers incidents like phishing attacks, which are not an engineering problem, but 3% of breaches did involve exploitable vulnerabilities, and according to the report, were predominantly older vulnerabilities and human error-led, like security misconfiguration. 

While those decrepit security bugs like XSS and SQL injection continue to trip up developers, increasingly, it has become apparent that core security design is failing, giving way to architectural vulnerabilities that can be very advantageous to a threat actor, especially if they go unpatched after the security flaw in a particular version of an application is made public. 

The trouble is, few engineers are given training and skills development that goes beyond the basics, and fewer still are truly having their knowledge and practical application expanded beyond localized, code-level bugs that are typically developer-introduced in the first place.

Preventing the bugs that robots rarely find

The newly grouped family of broken access control vulnerabilities is fairly diverse. You can find some specific examples of broken access controls and how to stop them on our YouTube channel and our blog. 

However, I think it’s important to celebrate this new OWASP Top 10; indeed, it is more varied, encompassing a wider range of attack vectors that include those that scanners won’t necessarily pick up. For every code-level weakness found, more complex architectural flaws will go unnoticed by most of the security tech stack, no matter how many automated shields and weapons are in the arsenal. While the lion’s share of the OWASP Top 10 list is still compiled based on scanning data, new entries covering insecure design and data integrity failures - among others - show that training horizons for developers need to expand rapidly to achieve what robots cannot.

Put simply, security scanners don’t make great threat modelers, but a team of security-skilled developers can help the AppSec team immeasurably by growing their security IQ in-line with best practices, as well as the needs of the business. This needs to be factored into a good security program, with the understanding that while the OWASP Top 10 is an excellent baseline, the threat landscape is so fast-paced (not to mention the demands of internal development goals) that there must be a plan to go deeper and more specific with developer upskilling in security. Failure to do so will inevitably lead to missed opportunities to remediate early, and hinder a successful holistic approach to preventative, human-led cybersecurity.

‍

We're OWASP Top 10 2021-ready, and that's just the beginning! Start your developers on an elevated security skills pathway today.

The cyber threat landscape is becoming more complex by the day. Attackers are constantly scanning networks for vulnerable applications, programs, cloud instances, and the latest flavor of the month is APIs, widely considered an easy win thanks to their often lax security controls. They are so persistent that new apps can sometimes be compromised and exploited within hours of deployment. The Verizon 2021 Data Breach Investigations Report makes it very clear that the threats leveled against businesses and organizations are more dangerous today than at any other point in history.

It’s becoming very clear that the only way to truly fortify the software being created is to ensure that it’s built on secure code. In other words, the best way to stop the threat actor invasion is to deny them a foothold into your applications in the first place. Once you start fighting that war, most of the advantages are skewed towards the attackers.

This situation first gave rise to agile development and DevOps, and later to the entire DevSecOps movement, where security is a shared responsibility for everyone involved in the process of creating software from development to deployment. But the base of that pyramid, and arguably the most important part, are the developers. While most developers want to do their part and write secure code, many of the organizations they work for are less supportive of the changes such a major shift in priorities requires. 

Defeat by design

For many years, developers were told that their primary role at their organizations was to quickly build and deploy apps in a fast-paced environment, where business never stops and customers never sleep. The faster that developers could code and the more features they could deploy, the more valuable they were seen in terms of their performance reviews.

Security was an afterthought, it if was considered at all. Instead, all of that was left to the application security (AppSec) teams to figure out. AppSec teams were disliked by most developers because they would often send completed applications back into development to apply security patches or to rewrite code to remediate vulnerabilities. And every hour that a developer spent working on an app that was already “finished” was an hour they were not creating new apps and features, thus decreasing their performance (and their value, in the eyes of a particularly punitive company).

And then the threat environment changed the importance and prioritization of security for most companies. According to the recent Cost of a Data Breach Report from IBM and the Ponemon Institute, the average cybersecurity breach now costs about $3.8 million per incident, although that is hardly the upper limit. One company alone incurred $1.3 billion in losses following a breach on their network. The companies of today want the security offered by DevSecOps, but, sadly, have been slow to reward developers who answer that call.

Simply telling the development teams to consider security won’t work, especially if they are still being incentivized based on speed alone. In fact, within such a system, developers who take the time to learn about security and secure their code could actually be losing out on better performance reviews and lucrative bonuses that their less-security-aware colleagues continue to earn. It’s almost like companies are unwittingly rigging the system for their own security failures, and it comes back to their perception of the development team. If they’re not seeing them as the security frontlines, then it’s very unlikely a viable plan to utilize their workforce will come to fruition.

And this doesn’t even account for the lack of training. Some very skilled developers have decades of experience coding, but very little when it comes to security… after all, it was never required of them. Unless a company provides a good training program to their skilled programmers, it can hardly expect their developers to suddenly gain new skills and put them into action in a meaningful way that actively reduces vulnerabilities.

Rewarding developers for good security practices

The good news is that the overwhelming majority of developers do their job because they find it both challenging and rewarding, and because they enjoy the respect that their position entails. Lifelong professional coder Michael Shpilt recently wrote about all of the things that motivate him and his coding colleagues in their development work. Yes, he lists monetary compensation among those incentives, but it’s surprisingly far down the list. Instead, he prioritizes the thrill of creating something new, learning new skills and the satisfaction of knowing that his work is going to be directly used to help others. He also talks about wanting to feel valued within his company and community. In short, developers are like a lot of good people who take pride in their work.

Developers like Shpilt and others don’t want threat actors compromising their code and using it to harm their company, or the very users they are trying to help. But, they can’t suddenly shift their priorities to security without support. Otherwise, It’s almost like the system will be working against them.

To help development teams improve their cybersecurity prowess, they must first be taught the necessary skills. Utilizing scaffolded learning, and tools like Just-in-Time (JiT) training can make this process much less painful, and helps to build upon existing knowledge in the right context. 

The principle of JiT is that developers are served the right knowledge at just the right time, for example, if a JiT developer training tool detects that a programmer is creating an insecure piece of code, or is accidentally introducing a vulnerability into their application, it can activate and show the developer how they could fix that problem, and how to write more secure code to perform that same function in the future.

With a commitment to upskilling in place, the old methods of evaluating developers based solely on speed need to be eliminated. Instead, coders should be rewarded based on their ability to create secure code, with the best developers becoming security champions that help the rest of the team improve their skills. And those champions need to be rewarded with both company prestige and monetary compensation. It’s also important to remember that developers don’t typically have a positive experience with security, and uplifting them with positive, fun learning and incentives that speak to their interests will go a long way to ensuring both knowledge retention and a desire to keep building skills.

Companies can still include coding speed as one part of a developer’s evaluation, but with the expectation that developing secure applications might take a little longer, especially as coders are learning those new skills.

DevSecOps can be the ultimate defense against the dark arts of an increasingly dangerous threat landscape. Just don’t forget that the champions of this new world, the developers who are consistently creating new code, need to be respected and compensated for their work.

Want to put your security skills to the test against other developers all over the world? Check out Secure Code Warrior’s Devlympics 2021, and you could take out a major prize in our global tournaments!

There have been some very welcome movements in the cybersecurity industry of late. It seems that sentiment around prioritizing security in software builds, as early as possible, is starting to improve in many organizations. This, coupled with official measures like Biden’s Executive Order on cybersecurity, has made it abundantly clear that everyone needs to be doing their part to ensure software security and data safety. What is especially exciting is that the conversation around the role of the developer in maintaining secure coding standards continues to evolve, even at the government level. 

However, there is something missing from the conversation. The Executive Order suggests that developers need verified security skills, yet no such official certification currently exists. Many companies remain guided by NIST (who provided updated guidelines in response to the EO) in their quest for compliance and higher standards of software security, but if we’re thinking of strategies to significantly reduce vulnerabilities, while incorporating the right tools and maintaining release velocity, most are simply too generic to create the desired outcome. This is where a lot of companies become unstuck, persevering with limited developer training, or not building upon general foundations to enable them with practical, hands-on skills. 

Security-aware developers do not grow on trees, but they can be nurtured and elevated much quicker with the right tools. To that end, we’re pleased to announce our own proprietary course for NIST compliance, as structured by the guidelines of the US Government’s Executive Order.

Meaningful, code-level support for developers

Using the NIST guidelines for Executive Order-critical (EO-critical) software here, we structured the course to hit the five key objectives that will, ultimately, improve the security of vital software in use at the highest levels of government, and should ideally act as a benchmark for higher quality development from the ground up.  

For true cut-through in a development cohort, any upskilling must go beyond theory, and be implemented in a way that doesn’t result in constant context-switching between work and training to find answers and stay agile. Meticulous security practices (not to mention the security team) are seen as blockers to on-time development sprints, and seriously cramp the style of the average feature-focused engineer. 

Short, snackable micro-learnings that are custom-fit to developer needs get a far less frosty reception, and result in memorable, practical skill-building. 

Take a look at how we’ve structured this for our NIST course:

Objective 1: Protect EO-critical software and EO-critical software platforms from unauthorized access and usage.‍

Security misconfiguration and improper authentication practices are relied upon by attackers to successfully infiltrate systems, take over accounts, and steal data. They are a common bug that can lead to huge problems if successfully exploited.

On the Secure Code Warrior Learning Platform, developers can play challenges based on real-world code snippets that accurately reflect how these bugs would appear in their everyday work, and get them to find an accurate solution to secure them. For the DevOps engineers, securing infrastructure requires meticulous access control configurations, and there are specialized challenges to meet this requirement in Infrastructure as Code (IaC) languages like Terraform, CloudFormation, and Ansible, as well as the code used in Docker and Kubernetes.

Objective 2: Protect the confidentiality, integrity, and availability of data used by EO-critical software and EO-critical software platforms.

For this objective, all roads lead to access control. Broken access control recently dethroned injection flaws as the top entry in the OWASP Top 10 2021, and it’s a serious bug that requires the skills of security-aware developers to find and fix as early as possible. 

The course deals with concepts like least privilege at the code level, and helps instill the approach of limiting access on user accounts to only the necessary areas as best practice.

Objective 3: Identify and maintain EO-critical software platforms and the software deployed to those platforms to protect the EO-critical software from exploitation.

One of the biggest challenges in large organizations is maintaining security oversight on all the different software, systems, and components currently in play. When it comes to risk management and patching, these elements must be a priority in any security program, with developers on high alert to perform security maintenance. 

On the Secure Code Warrior Learning Platform, developers can play challenges that will help them identify and fix vulnerable components, as well as permissions-based security misconfiguration.

Objective 4: Quickly detect, respond to, and recover from threats and incidents involving EO-critical software and EO-critical software platforms.

It’s unfortunate (and a waste of time and money) that many organizations still focus on incident response - as opposed to prevention - when dealing with cybersecurity issues. This is a culture that we’re fighting to change, and developers are at the helm of providing preventative firepower when properly trained in security best practices. 

Objective 4 requires developers, in the context of their role, to continuously monitor security in their environments, and endpoints both at the software and network level. Insufficient logging and monitoring is another common, insidious bug, and it’s vital that engineers are able to successfully navigate this in their everyday tasks.

On the Secure Code Warrior Learning Platform, developers can play challenges to hone these skills, whether working with web, API, or cloud languages.

Security awareness with sustainability.

Objective 5: Strengthen the understanding and performance of humans’ actions that foster the security of EO-critical software and EO-critical software platforms.

This one is quite generalized, but it’s the most important to achieve… and you can’t do it without mastering the first four objectives. This guideline asks that frequent security awareness activities are carried out, and that all “human actions” on EO-critical software are carried out by those who are adequately trained in the context of their roles and responsibilities.

Developers are among those who are most up close and personal with code, in addition to security configurations and access control. Their security skills must be nurtured, and to achieve the high standards as outlined by NIST, a hands-on course structure might just be the efficient way to tackle it, especially with large development cohorts. 

Start adding to your development team’s experience points and security IQ today.