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
Professional Services - Accelerate with expertise
Secure Code Warrior’s Program Strategy Services (PSS) team helps you build, enhance, and optimize your secure coding program. Whether you're starting fresh or refining your approach, our experts provide tailored guidance.
Secure code training topics & content
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peak of what our content catalog has to offer by topic and role.
Quests: Industry leading learning to keep developers ahead of the game mitigating risk.
Quests is a learning platform that helps developers mitigate software security risks by enhancing their secure coding skills. With curated learning paths, hands-on challenges, and interactive activities, it empowers developers to identify and prevent vulnerabilities.
Resources to get you started
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.
The Decade of the Defenders: Secure Code Warrior Turns Ten
Secure Code Warrior's founding team has stayed together, steering the ship through every lesson, triumph, and setback for an entire decade. We’re scaling up and ready to face our next chapter, SCW 2.0, as the leaders in developer risk management.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
