DevSecOps: The Old Security Bugs Still Performing New Tricks
Originally published on DevOps.com.
In cybersecurity, we are often like hunters. Our eyes are firmly glued to the horizon, scanning for the next breakout vulnerability (along with the right designing tools, techniques and tactics to stop it). However, this forward-looking focus can have the surprising effect of dampening our overall security awareness, blinding us to deep-seated dangers that exist all around, and which attackers are all too happy to exploit.
I often compare modern cybersecurity to a suit of Kevlar armor. The seemingly ethereal properties of Kevlar can block high-velocity rounds and all manner of modern, powerful weaponry. It may even make a wearer feel somewhat invincible. However, a comparatively ancient bow and arrow weapon system, first crafted sometime around 1000 B.C., can often penetrate that protection. A sharp knife, probably the second oldest weapon in the world behind rocks, can slice right though Kevlar as easily as if it were shredding a cotton sweatshirt. And then there's the little matter of Kevlar not being able to protect every single millimeter of the human body. If an attacker can find any gap to deliver a damaging blow, they will"much like small, exploitable areas in software.
In cybersecurity, many organizations are similarly vulnerable to flaws on systems that are eight or 10 years old, which in modern computing terms just about qualifies them for a gold watch and a pension. But if you think flaws on these elderly systems are harmless, then you've probably got a blue screen of death or two in your future.
A Vulnerability for a Veteran
One of the oldest and most used JavaScript libraries is jQuery, an open source resource that helps with everything from event handling, to DOM tree traversal and manipulation, to generating animations. It's quite a workhorse, and has been used for many years. People assume that because the library is so established at this point, that it must have been completely vetted, with any vulnerabilities removed.
Sadly, this is not the case. By default, most applications that rely on jQuery use the internal library's instructions for authentication. For example, with Apache servers, this means checking the .htaccess files. Few developers designing programs that use Apache probably thought to check to make sure that Apache server updates included .htaccess. After all, why would Apache remove that critical component, which has been a bedrock of security for years?
As strange as it may seem, that is exactly what Apache did in version 2.3.9. Apparently, having to check the .htaccess configuration files every time a program needed to run was slowing things down too much. Removing it improved overall Apache performance, but also created a vulnerability that most people didn't know about. If developers didn't bother to check to see if their apps could still reach the .htaccess files, most requests would simply be accepted without scrutiny.
Recently, experts discovered that flaw and noted that using it would allow unauthorized users to upload and run shells or almost any type of code on supposedly secure systems. This led to the creation of a vulnerability alert designated CVE-2018-9206 in October. But, the ease at which the flaw was discovered by a security researcher implies that professional hackers, whose sole aim is to search for vulnerabilities such as this, probably already have discovered it. After all, despite the publicity, patches and fixes brought about in the aftermath, a similar high-impact attack happened just a few weeks later, in which Bitcoin-thieving malware was unleashed on a popular NPM lib downloaded by millions every week.
The Butler Did It
Like jQuery, Jenkins is an open source offering, and one of the most popular of its kind. With its helpful servant-like name, it makes sense that Jenkins is used as an automation server by development teams in many industries. When Jenkins is functioning correctly, it's an extremely helpful tool. However, newly discovered flaws, and one recently uncovered crypto mining operation that is truly massive in scale, suggests that Jenkins was also doing a lot of work for the bad guys.
One of the most dangerous Jenkins vulnerabilities is called Java deserialization, which is designated as CVE-2017-1000353. It's a complex attack, but one that has been around for a while. An attacker must submit two requests. The first one starts a bidirectional channel for downloading which is initially rejected by the server. However, the second request adds an upload channel which contains a payload with whatever commands the attacker wants, and utilizes the payload.jar script. Once the second request is sent, the communication is allowed on unpatched Jenkins servers.
Even on patched servers, exploits exist. For example, when running Jenkins in a Windows environment, by default it uses the NT AUTHORITY\SYSTEM account to authorize users. This is dangerous because SYSTEM is granted full permissions on Windows servers. Developers can change the authority account, but often don't. Their logic not to do so is based on the fact that Jenkins has been around forever, so people figure that any vulnerabilities have been patched a long time ago.
Most recently, a hacker used these aging Jenkins vulnerabilities to compromise several servers. The goal was adding a crypto miner program on every vulnerable Jenkins instance they could find. The miners took up valuable computing resources in their constant search for cryptocurrency. So far, they have found approximately 10,800 Monero crypto coins, with a value of almost $3.5 million.
What is Old is New Again
In both of these examples, vulnerabilities are being exploited by opportunistic attackers on platforms that many people consider to be safe. On the defensive side, the lack of security-aware development is allowing these hackers to breathe new life into old tricks. And despite a new round of success using aging vulnerabilities, many organizations have no plan in place to stop this vicious cycle.
Just because something is old does not mean that it's harmless. And just because common libraries and resources have been around for years doesn't mean that they are completely secure (for example, the No. 9 entry in the current OWASP top 10 is dedicated to dealing with Using Components With Known Vulnerabilities). Only through diligence and constant security training can we protect ourselves not only from dangerous threats creeping over the horizon, but also those which have already settled insidiously into our own backyards.
In cybersecurity, we are often like hunters. Our eyes are firmly glued to the horizon, scanning for the next breakout vulnerability. However, this forward-looking focus can have the surprising effect of dampening our overall security awareness.
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
Chief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
Originally published on DevOps.com.
In cybersecurity, we are often like hunters. Our eyes are firmly glued to the horizon, scanning for the next breakout vulnerability (along with the right designing tools, techniques and tactics to stop it). However, this forward-looking focus can have the surprising effect of dampening our overall security awareness, blinding us to deep-seated dangers that exist all around, and which attackers are all too happy to exploit.
I often compare modern cybersecurity to a suit of Kevlar armor. The seemingly ethereal properties of Kevlar can block high-velocity rounds and all manner of modern, powerful weaponry. It may even make a wearer feel somewhat invincible. However, a comparatively ancient bow and arrow weapon system, first crafted sometime around 1000 B.C., can often penetrate that protection. A sharp knife, probably the second oldest weapon in the world behind rocks, can slice right though Kevlar as easily as if it were shredding a cotton sweatshirt. And then there's the little matter of Kevlar not being able to protect every single millimeter of the human body. If an attacker can find any gap to deliver a damaging blow, they will"much like small, exploitable areas in software.
In cybersecurity, many organizations are similarly vulnerable to flaws on systems that are eight or 10 years old, which in modern computing terms just about qualifies them for a gold watch and a pension. But if you think flaws on these elderly systems are harmless, then you've probably got a blue screen of death or two in your future.
A Vulnerability for a Veteran
One of the oldest and most used JavaScript libraries is jQuery, an open source resource that helps with everything from event handling, to DOM tree traversal and manipulation, to generating animations. It's quite a workhorse, and has been used for many years. People assume that because the library is so established at this point, that it must have been completely vetted, with any vulnerabilities removed.
Sadly, this is not the case. By default, most applications that rely on jQuery use the internal library's instructions for authentication. For example, with Apache servers, this means checking the .htaccess files. Few developers designing programs that use Apache probably thought to check to make sure that Apache server updates included .htaccess. After all, why would Apache remove that critical component, which has been a bedrock of security for years?
As strange as it may seem, that is exactly what Apache did in version 2.3.9. Apparently, having to check the .htaccess configuration files every time a program needed to run was slowing things down too much. Removing it improved overall Apache performance, but also created a vulnerability that most people didn't know about. If developers didn't bother to check to see if their apps could still reach the .htaccess files, most requests would simply be accepted without scrutiny.
Recently, experts discovered that flaw and noted that using it would allow unauthorized users to upload and run shells or almost any type of code on supposedly secure systems. This led to the creation of a vulnerability alert designated CVE-2018-9206 in October. But, the ease at which the flaw was discovered by a security researcher implies that professional hackers, whose sole aim is to search for vulnerabilities such as this, probably already have discovered it. After all, despite the publicity, patches and fixes brought about in the aftermath, a similar high-impact attack happened just a few weeks later, in which Bitcoin-thieving malware was unleashed on a popular NPM lib downloaded by millions every week.
The Butler Did It
Like jQuery, Jenkins is an open source offering, and one of the most popular of its kind. With its helpful servant-like name, it makes sense that Jenkins is used as an automation server by development teams in many industries. When Jenkins is functioning correctly, it's an extremely helpful tool. However, newly discovered flaws, and one recently uncovered crypto mining operation that is truly massive in scale, suggests that Jenkins was also doing a lot of work for the bad guys.
One of the most dangerous Jenkins vulnerabilities is called Java deserialization, which is designated as CVE-2017-1000353. It's a complex attack, but one that has been around for a while. An attacker must submit two requests. The first one starts a bidirectional channel for downloading which is initially rejected by the server. However, the second request adds an upload channel which contains a payload with whatever commands the attacker wants, and utilizes the payload.jar script. Once the second request is sent, the communication is allowed on unpatched Jenkins servers.
Even on patched servers, exploits exist. For example, when running Jenkins in a Windows environment, by default it uses the NT AUTHORITY\SYSTEM account to authorize users. This is dangerous because SYSTEM is granted full permissions on Windows servers. Developers can change the authority account, but often don't. Their logic not to do so is based on the fact that Jenkins has been around forever, so people figure that any vulnerabilities have been patched a long time ago.
Most recently, a hacker used these aging Jenkins vulnerabilities to compromise several servers. The goal was adding a crypto miner program on every vulnerable Jenkins instance they could find. The miners took up valuable computing resources in their constant search for cryptocurrency. So far, they have found approximately 10,800 Monero crypto coins, with a value of almost $3.5 million.
What is Old is New Again
In both of these examples, vulnerabilities are being exploited by opportunistic attackers on platforms that many people consider to be safe. On the defensive side, the lack of security-aware development is allowing these hackers to breathe new life into old tricks. And despite a new round of success using aging vulnerabilities, many organizations have no plan in place to stop this vicious cycle.
Just because something is old does not mean that it's harmless. And just because common libraries and resources have been around for years doesn't mean that they are completely secure (for example, the No. 9 entry in the current OWASP top 10 is dedicated to dealing with Using Components With Known Vulnerabilities). Only through diligence and constant security training can we protect ourselves not only from dangerous threats creeping over the horizon, but also those which have already settled insidiously into our own backyards.
Originally published on DevOps.com.
In cybersecurity, we are often like hunters. Our eyes are firmly glued to the horizon, scanning for the next breakout vulnerability (along with the right designing tools, techniques and tactics to stop it). However, this forward-looking focus can have the surprising effect of dampening our overall security awareness, blinding us to deep-seated dangers that exist all around, and which attackers are all too happy to exploit.
I often compare modern cybersecurity to a suit of Kevlar armor. The seemingly ethereal properties of Kevlar can block high-velocity rounds and all manner of modern, powerful weaponry. It may even make a wearer feel somewhat invincible. However, a comparatively ancient bow and arrow weapon system, first crafted sometime around 1000 B.C., can often penetrate that protection. A sharp knife, probably the second oldest weapon in the world behind rocks, can slice right though Kevlar as easily as if it were shredding a cotton sweatshirt. And then there's the little matter of Kevlar not being able to protect every single millimeter of the human body. If an attacker can find any gap to deliver a damaging blow, they will"much like small, exploitable areas in software.
In cybersecurity, many organizations are similarly vulnerable to flaws on systems that are eight or 10 years old, which in modern computing terms just about qualifies them for a gold watch and a pension. But if you think flaws on these elderly systems are harmless, then you've probably got a blue screen of death or two in your future.
A Vulnerability for a Veteran
One of the oldest and most used JavaScript libraries is jQuery, an open source resource that helps with everything from event handling, to DOM tree traversal and manipulation, to generating animations. It's quite a workhorse, and has been used for many years. People assume that because the library is so established at this point, that it must have been completely vetted, with any vulnerabilities removed.
Sadly, this is not the case. By default, most applications that rely on jQuery use the internal library's instructions for authentication. For example, with Apache servers, this means checking the .htaccess files. Few developers designing programs that use Apache probably thought to check to make sure that Apache server updates included .htaccess. After all, why would Apache remove that critical component, which has been a bedrock of security for years?
As strange as it may seem, that is exactly what Apache did in version 2.3.9. Apparently, having to check the .htaccess configuration files every time a program needed to run was slowing things down too much. Removing it improved overall Apache performance, but also created a vulnerability that most people didn't know about. If developers didn't bother to check to see if their apps could still reach the .htaccess files, most requests would simply be accepted without scrutiny.
Recently, experts discovered that flaw and noted that using it would allow unauthorized users to upload and run shells or almost any type of code on supposedly secure systems. This led to the creation of a vulnerability alert designated CVE-2018-9206 in October. But, the ease at which the flaw was discovered by a security researcher implies that professional hackers, whose sole aim is to search for vulnerabilities such as this, probably already have discovered it. After all, despite the publicity, patches and fixes brought about in the aftermath, a similar high-impact attack happened just a few weeks later, in which Bitcoin-thieving malware was unleashed on a popular NPM lib downloaded by millions every week.
The Butler Did It
Like jQuery, Jenkins is an open source offering, and one of the most popular of its kind. With its helpful servant-like name, it makes sense that Jenkins is used as an automation server by development teams in many industries. When Jenkins is functioning correctly, it's an extremely helpful tool. However, newly discovered flaws, and one recently uncovered crypto mining operation that is truly massive in scale, suggests that Jenkins was also doing a lot of work for the bad guys.
One of the most dangerous Jenkins vulnerabilities is called Java deserialization, which is designated as CVE-2017-1000353. It's a complex attack, but one that has been around for a while. An attacker must submit two requests. The first one starts a bidirectional channel for downloading which is initially rejected by the server. However, the second request adds an upload channel which contains a payload with whatever commands the attacker wants, and utilizes the payload.jar script. Once the second request is sent, the communication is allowed on unpatched Jenkins servers.
Even on patched servers, exploits exist. For example, when running Jenkins in a Windows environment, by default it uses the NT AUTHORITY\SYSTEM account to authorize users. This is dangerous because SYSTEM is granted full permissions on Windows servers. Developers can change the authority account, but often don't. Their logic not to do so is based on the fact that Jenkins has been around forever, so people figure that any vulnerabilities have been patched a long time ago.
Most recently, a hacker used these aging Jenkins vulnerabilities to compromise several servers. The goal was adding a crypto miner program on every vulnerable Jenkins instance they could find. The miners took up valuable computing resources in their constant search for cryptocurrency. So far, they have found approximately 10,800 Monero crypto coins, with a value of almost $3.5 million.
What is Old is New Again
In both of these examples, vulnerabilities are being exploited by opportunistic attackers on platforms that many people consider to be safe. On the defensive side, the lack of security-aware development is allowing these hackers to breathe new life into old tricks. And despite a new round of success using aging vulnerabilities, many organizations have no plan in place to stop this vicious cycle.
Just because something is old does not mean that it's harmless. And just because common libraries and resources have been around for years doesn't mean that they are completely secure (for example, the No. 9 entry in the current OWASP top 10 is dedicated to dealing with Using Components With Known Vulnerabilities). Only through diligence and constant security training can we protect ourselves not only from dangerous threats creeping over the horizon, but also those which have already settled insidiously into our own backyards.
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
Chief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
Originally published on DevOps.com.
In cybersecurity, we are often like hunters. Our eyes are firmly glued to the horizon, scanning for the next breakout vulnerability (along with the right designing tools, techniques and tactics to stop it). However, this forward-looking focus can have the surprising effect of dampening our overall security awareness, blinding us to deep-seated dangers that exist all around, and which attackers are all too happy to exploit.
I often compare modern cybersecurity to a suit of Kevlar armor. The seemingly ethereal properties of Kevlar can block high-velocity rounds and all manner of modern, powerful weaponry. It may even make a wearer feel somewhat invincible. However, a comparatively ancient bow and arrow weapon system, first crafted sometime around 1000 B.C., can often penetrate that protection. A sharp knife, probably the second oldest weapon in the world behind rocks, can slice right though Kevlar as easily as if it were shredding a cotton sweatshirt. And then there's the little matter of Kevlar not being able to protect every single millimeter of the human body. If an attacker can find any gap to deliver a damaging blow, they will"much like small, exploitable areas in software.
In cybersecurity, many organizations are similarly vulnerable to flaws on systems that are eight or 10 years old, which in modern computing terms just about qualifies them for a gold watch and a pension. But if you think flaws on these elderly systems are harmless, then you've probably got a blue screen of death or two in your future.
A Vulnerability for a Veteran
One of the oldest and most used JavaScript libraries is jQuery, an open source resource that helps with everything from event handling, to DOM tree traversal and manipulation, to generating animations. It's quite a workhorse, and has been used for many years. People assume that because the library is so established at this point, that it must have been completely vetted, with any vulnerabilities removed.
Sadly, this is not the case. By default, most applications that rely on jQuery use the internal library's instructions for authentication. For example, with Apache servers, this means checking the .htaccess files. Few developers designing programs that use Apache probably thought to check to make sure that Apache server updates included .htaccess. After all, why would Apache remove that critical component, which has been a bedrock of security for years?
As strange as it may seem, that is exactly what Apache did in version 2.3.9. Apparently, having to check the .htaccess configuration files every time a program needed to run was slowing things down too much. Removing it improved overall Apache performance, but also created a vulnerability that most people didn't know about. If developers didn't bother to check to see if their apps could still reach the .htaccess files, most requests would simply be accepted without scrutiny.
Recently, experts discovered that flaw and noted that using it would allow unauthorized users to upload and run shells or almost any type of code on supposedly secure systems. This led to the creation of a vulnerability alert designated CVE-2018-9206 in October. But, the ease at which the flaw was discovered by a security researcher implies that professional hackers, whose sole aim is to search for vulnerabilities such as this, probably already have discovered it. After all, despite the publicity, patches and fixes brought about in the aftermath, a similar high-impact attack happened just a few weeks later, in which Bitcoin-thieving malware was unleashed on a popular NPM lib downloaded by millions every week.
The Butler Did It
Like jQuery, Jenkins is an open source offering, and one of the most popular of its kind. With its helpful servant-like name, it makes sense that Jenkins is used as an automation server by development teams in many industries. When Jenkins is functioning correctly, it's an extremely helpful tool. However, newly discovered flaws, and one recently uncovered crypto mining operation that is truly massive in scale, suggests that Jenkins was also doing a lot of work for the bad guys.
One of the most dangerous Jenkins vulnerabilities is called Java deserialization, which is designated as CVE-2017-1000353. It's a complex attack, but one that has been around for a while. An attacker must submit two requests. The first one starts a bidirectional channel for downloading which is initially rejected by the server. However, the second request adds an upload channel which contains a payload with whatever commands the attacker wants, and utilizes the payload.jar script. Once the second request is sent, the communication is allowed on unpatched Jenkins servers.
Even on patched servers, exploits exist. For example, when running Jenkins in a Windows environment, by default it uses the NT AUTHORITY\SYSTEM account to authorize users. This is dangerous because SYSTEM is granted full permissions on Windows servers. Developers can change the authority account, but often don't. Their logic not to do so is based on the fact that Jenkins has been around forever, so people figure that any vulnerabilities have been patched a long time ago.
Most recently, a hacker used these aging Jenkins vulnerabilities to compromise several servers. The goal was adding a crypto miner program on every vulnerable Jenkins instance they could find. The miners took up valuable computing resources in their constant search for cryptocurrency. So far, they have found approximately 10,800 Monero crypto coins, with a value of almost $3.5 million.
What is Old is New Again
In both of these examples, vulnerabilities are being exploited by opportunistic attackers on platforms that many people consider to be safe. On the defensive side, the lack of security-aware development is allowing these hackers to breathe new life into old tricks. And despite a new round of success using aging vulnerabilities, many organizations have no plan in place to stop this vicious cycle.
Just because something is old does not mean that it's harmless. And just because common libraries and resources have been around for years doesn't mean that they are completely secure (for example, the No. 9 entry in the current OWASP top 10 is dedicated to dealing with Using Components With Known Vulnerabilities). Only through diligence and constant security training can we protect ourselves not only from dangerous threats creeping over the horizon, but also those which have already settled insidiously into our own backyards.
Table of contents
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Resources to get you started
10 Key Predictions: Secure Code Warrior on AI & Secure-by-Design’s Influence in 2025
Organizations are facing tough decisions on AI usage to support long-term productivity, sustainability, and security ROI. It’s become clear to us over the last few years that AI will never fully replace the role of the developer. From AI + developer partnerships to the increasing pressures (and confusion) around Secure-by-Design expectations, let’s take a closer look at what we can expect over the next year.
OWASP Top 10 For LLM Applications: What’s New, Changed, and How to Stay Secure
Stay ahead in securing LLM applications with the latest OWASP Top 10 updates. Discover what's new, what’s changed, and how Secure Code Warrior equips you with up-to-date learning resources to mitigate risks in Generative AI.
Trust Score Reveals the Value of Secure-by-Design Upskilling Initiatives
Our research has shown that secure code training works. Trust Score, using an algorithm drawing on more than 20 million learning data points from work by more than 250,000 learners at over 600 organizations, reveals its effectiveness in driving down vulnerabilities and how to make the initiative even more effective.
.png)
Reactive Versus Preventive Security: Prevention Is a Better Cure
The idea of bringing preventive security to legacy code and systems at the same time as newer applications can seem daunting, but a Secure-by-Design approach, enforced by upskilling developers, can apply security best practices to those systems. It’s the best chance many organizations have of improving their security postures.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
