devopsy.kinsta.cloud

Author: Pieter Danhieux

  • I Guess This is Growing Up: Devs and CISA’s Secure-by-Design Guidelines

    I Guess This is Growing Up: Devs and CISA’s Secure-by-Design Guidelines

    With the downward pressure of a global recession, inflation and general post-pandemic turbulence underpinning disruption to multiple facets of life, it seems only fair that we in the IT, software and security industry would eventually feel the winds of change, too. We have rolled with the punches of escalating cybercrime and data breaches; the collective, fragmented sheriffs of a digital Wild West, and it’s high time we updated our strategy for safeguarding software against bad actors who seek to do widespread harm.

    The recently released National Cybersecurity Strategy signals the need for a seismic cultural shift for most companies and their developers and DevOps teams. The most glaring recommendation comes in the form of security accountability that falls primarily on software vendors. This is a positive step, though it is sure to cause teething problems, especially as many organizations struggle to accurately assess their security maturity across the board, particularly among the development cohort.

    Since CISA Director Jen Easterly’s trailblazing speech on secure design principles, we have eagerly awaited formal guidelines on how, exactly, organizations can approach this significant restructuring of software development as we know it. Thanks to a collaborative effort between the cybersecurity authorities of seven countries, we have a rather comprehensive overview of how to drive down vulnerabilities in software.

    This should be cause for celebration, but understandably, there is hesitation about how this will impact innovation, feature delivery and, ultimately, the bottom line as the pressure of security stewardship mounts for vendors. We’ve grown accustomed to dealing with cumbersome tooling that is ill-fitted with developer workflows, overwhelming them with a list of fixes in an information avalanche. Add SCA and SAST scanning, and you’ve got thousands of identified issues in a codebase that are just not practical to solve. 

    Despite this, in terms of our collective attitude towards code-level security, is it time we grew up and faced the music?

    Security Commitment and Transparency Boost Our Potential

    Back in March, the White House announced that one of its top priorities in the National Cybersecurity Strategy was to shake things up and start holding entities liable for sloppy software security measures:

    “Companies that make software must have the freedom to innovate, but they must also be held liable when they fail to live up to the duty of care they owe consumers, businesses or critical infrastructure providers,” the White House noted in the strategy.

    In the era of “speed at all costs” software development, my opinion may be unpopular, but I truly stand behind the idea that coding with security front-of-mind from the beginning is the only way we safely create our digital future. We were already facing insurmountable challenges with data breaches, nation-state attacks and infrastructure disruption, and that was before code-capable AI tools hit the mainstream. Until every person touching code cares more about the security implications of their actions, we will continue to see cybersecurity issues surge at a rapid rate.

    I know this is easier said than done. I have a lot of empathy for those standing at the bottom of this steep mountain trying to change the conversation around security accountability and enable developers in their organizations to share responsibility. To adequately fulfill key secure-by-design principles in software development, it is going to require precision training that establishes a basic skillset before deep-diving into more advanced security architecture methods. Developer-led threat modeling is a golden opportunity for the AppSec and development teams to work together toward a common goal and explore access control and insecure design pitfalls that plague less mature organizations.

    Still, the core issue has always revolved around a lack of ownership for security (until something goes wrong—then it’s the AppSec team left holding the bag) coupled with a low appetite for best practices to be established and executed across every part of the SDLC. The truth is, it was never acceptable for developers to start coding with so little security expertise, nor for us to focus on speed and functionality at the expense of safety and quality. Yet, here we are, and this is our crucible moment to accept shorter-term pain for longer-term ongoing success.

    We should want to create the most secure, robust software possible, and the “radical transparency” called for by Jen Easterly is a boon to vendors and clients alike. It is definitely a mark of value to showcase the company’s security prowess; brand trust and reputation are everything in this hyper-competitive landscape.

    Developers Need Guidance and Support to Thrive in a Secure-by-Default Environment

    The CISA guidelines pay particular attention to open-source and third-party components, both of which are widely used in most software development projects. It is imperative that developers are sufficiently security-aware to navigate potential inherent bugs with any preexisting code they use. However, in addition, they must be able to apply working knowledge of security fundamentals in the languages and frameworks they actively write in every day. Annual compliance videos played at 2x speed won’t cut it; they need training and a tech stack that is hyper-relevant, easy to access without context-switching from their workspace and that ultimately drives them to apply secure coding best practices as second nature.

    They cannot do this alone, and they can’t be expected to upskill in their own time. The cultural shift required to make the development team a fundamental cog in a thriving security program takes courage, time and commitment. But the reward is cohesion between AppSec and developers that would have been virtually impossible a decade ago and software that stands above those who are, in one way or another, happy to let security slide despite the risks.

    I guess this is what growing up looks like for all of us in the software industry, and it’s crucial if we want to stop the same old vulnerabilities that have plagued us for so long that they are old enough to drink.

  • Competing Priorities Prevent Devs From Creating Secure Code

    Competing Priorities Prevent Devs From Creating Secure Code

    The recently released Secure Code Warrior State of Developer-Driven Security Survey revealed that developers continue to wrestle with secure coding practices in a working environment that has long prioritized features and functionality and speed at the expense of security. 

    Of the more than 1,200 developers who took part in the survey, only 14% named security as their top priority. Security was seen as a bottleneck—an astonishing 67% of these developers said they routinely left known vulnerabilities and exploits in their code and 48% shipped products with known vulnerabilities.

    These statistics raise eyebrows, sure, but they are also unsurprising. In the survey, application security fell behind creating quality code, application performance and the ability to solve real-world problems on the list of developers’ priorities.

    In many cases, these results showed that security is either ignored in favor of meeting demanding timelines, developers would rather improve an application’s performance or they simply lack the required training to fix security problems. Regardless of the reason, it is a continuing problem.

    The Need to Balance Security in Development

    As the survey showed, developers often worked with secure code in silos. Security controls were limited to a single category instead of a holistic view of fundamentals. In many cases, developers relied on existing or pre-approved code rather than writing new code free from vulnerabilities. This assumed that the code inserted meets proper security needs, but that assumption often fell short.

    That said, developers who write code often find themselves inadvertently introducing vulnerabilities. This is not entirely the fault of those developers, but some of the blame lies with the cultural risk acceptance of the organization.

    The software organizations themselves must put more onus on secure development. As we saw from the SolarWinds attack, deficiencies in code can lead to massive disruptions. While not all application vulnerabilities have the reach of SolarWinds, businesses often allow for too much risk to pass in their code; that gets passed on to customers and developers are made the scapegoats.

    Provide Developers With the Right Skills

    Security leaders must first ensure developers have the requisite skills to code securely and to make improvements. That includes not just writing the code but also how code is committed through the entire development process. Developers often need hands-on training in proper coding patterns created in the languages and frameworks they commonly use.

    Organizations can no longer overlook security and ship potentially exploitable software. Security must be added earlier in the development process and be seen as imperative to success. The survey showed that many developers believe secure coding is out of their realm of expertise. A staggering 86% said they found it challenging to practice secure coding, while 92% of developer managers said their teams needed more training in security frameworks.

    This highlighted that developers do not get the right kind of training—nor are they get enough exposure to security best practices. It also underscores that designing for security is not seen as an essential skill for developers to have.

    Reasons for Optimism

    While our survey highlighted a disturbing trend, it also offered reasons for hope. The survey showed that attitudes have changed, and 66% of developers expected security to become a more significant priority over the next 12 to 18 months. Hiring managers echoed this sentiment—82% expressed an interest in hiring developers who are knowledgeable in security over those who are not.

    Businesses today have put themselves and their customers in a risky situation; organizational leaders must be agents of change to mitigate this risk. They need to apply a security-first mindset and empower their developers to better integrate security into the development process. Timelines must be revised to allow this to happen. If it continues, the current state of application security will only lead to more (and more severe) breaches. Now is the time to ensure DevOps teams and developers have better access to security training and more time to put those practices into action to ensure long term success. 

  • Improving Software Security in 2022

    Improving Software Security in 2022

    The recent Log4j vulnerability showed just how quickly a security bug could disrupt not just an industry, but the entire world.

    Organizations, especially federal agencies, will always find themselves at some level of risk, but they can also do more to mitigate those challenges. In November 2021, the Biden administration issued a directive through the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) to fix hundreds of software and hardware vulnerabilities. 

    While this effort created an immediate call-to-action to patch known security risks, organizations from all industries must constantly manage known and unknown threats. A study released in July 2021 found it took organizations an average of 205 days to fix critical vulnerabilities, a timeframe that provided bad actors a wealth of opportunity to conduct serious damage.

    Agencies must adopt a more proactive approach to cybersecurity by improving software code quality. Let’s look at how to do that.

    An Ounce of Prevention

    Shaking up the status quo does tend to raise a few eyebrows, but the truth is that security programs should be in a constant state of continuous improvement. Today, our security programs work in an overly reactive state that relies too heavily on mitigation once a threat has emerged.

    Emphasizing a preventative approach may not be widely understood outside the security team, especially when an agency has a relatively clean security record. It might be seen as something that isn’t broken and, therefore, doesn’t need fixing. In this instance, getting leadership buy-in at all levels of an agency is important.

    Some pertinent points security executives should emphasize to change security culture inside their organization include:

    • The time and cost savings achieved through preventative measures, such as role-based training and related tools, as opposed to the potential cost of a critical incident.
    • Finding and fixing software vulnerabilities as code is written keeps releases on time with fewer showstoppers from the security team.
    • Preparing for and preempting potential security risks from the development team to release saves time and money overall. 

    Shifting Left of Left

    Shifting left has been popular in Agile and DevOps environments for over a decade. It involves testing small software components as early as possible rather than waiting until the end of the sprint.

    To create more secure code, organizations need to start left of left, eliminating common vulnerabilities as early as possible to create a safer user experience. 

    Starting left of left is a developer-first concept and requires organizations to get serious about uplifting their engineering cohort, placing emphasis on the creation of high-quality code. Security-aware developers are worth their weight in gold, and they need support in the form of job-relevant, hands-on training in secure code as well as the ability to provision the right tools. The opportunity to be mentored by more experienced developers will also foster an environment where code is crafted with a security-first mindset and the precision required to take software to the next level.

    One key area that often gets overlooked is the user experience; particularly with regard to how users access information.

    Security misconfigurations accounted for 21% of cloud-based data breaches in the past year, and amateur-hour errors (like storing passwords in plaintext, for example) resulted in serious productivity and customer trust losses. To avoid these errors, aim for a secure user experience that weaves tight security into a flow that makes sense. Adding more barriers—complex password requirements, a CAPTCHA, a horde of flesh-eating zombies—can turn users away. On the other hand, getting too permissive with security measures renders the entire point moot.

    A successful, secure user experience needs to weave tight security into a flow that makes sense, presented in a way that doesn’t detract from anything compelling about the software. 

    Improved Developer Upskilling

    Developers, of course, want to write secure code, but they often lack those skills or need a refresher course. Meaningful training too often gets overlooked as the day-to-day needs of organizations allow for little time to improve skills.

    In working with developers, we’ve found that about 75% prefer structured on-the-job learning instead of opening a manual. They would rather learn by doing and want training focused on practical applications, something that most current training programs are missing.

    Look for any and all opportunities to upskill your developers. They are on the front lines when it comes to stopping vulnerabilities. Provide them both the time and right-fit resources, understanding that these efforts will pay considerable dividends in the future.

    Government agencies, in particular, face inherent challenges in keeping their systems secure. They often must manage outdated systems with few financial resources and fight for top talent in an incredibly competitive market. There is no panacea for removing vulnerabilities, but taking a proactive and preventative approach that emphasizes the customer experience with highly skilled developers can help agencies take significant steps forward.

  • Why DevOps Implementation is Often Unsuccessful – and How to Fix It

    Why DevOps Implementation is Often Unsuccessful – and How to Fix It

    Much like “blockchain” and “big data,” the term “DevOps” is another buzzword currently being thrown around the IT departments of large organizations.

    Many have identified the need for faster software development life cycles; a more precise process closely aligned with business objectives, allowing for clearer workflow and collaboration between the development and operations teams. DevOps is essentially agile, all grown up and ready to take on the constantly innovating and rapidly deploying needs of the modern business.

    For security professionals, it’s a fantastic initiative: We can inject security into the process far earlier, reducing the cost of fixing bugs and avoiding potential catastrophe down the track.

    The problem is, few companies are truly successful in their DevOps implementation. Without the right support, nurturing and understanding across the business, it can quickly become a white elephant, you know, one of those “don’t mention the war” projects.

    So, what’s the problem? There are a few ways to approach DevOps that I believe will make for much smoother sailing. An effective program goes beyond a few fancy new tools, titles and team meetings. It’s not always going to be easy but taking the time to fix a broken strategy (or implement it the right way from start) is going to be far less painful in the long run. Ultimately, it’s going to result in higher quality and more secure software.

    Let’s break it down.

    Let Go of the Agile Apron Strings

    There is somewhat of a misconception that an organization must choose between agile or DevOps, setting down one path or the other, never to look back.

    The thing is, the development process works best when both are being considered and implemented as one. DevOps is not a reinvention of agile development; rather, it is an extension of it. The wheels tend to fall off when there is an expectation the process will be exactly agile, or completely different from agile.

    Agile supports the principle of cross-functional teams, bringing designers, testers and developers together from the beginning and committing to open communication lines throughout a project. Its aim is to stop siloed delivery and reduce double-handling, both of which are benefits of the DevOps process as well. However, DevOps goes a step further, introducing systems, security and operations into the mix to offer a robust, end-to-end skillset that had the ultimate goal of full, functional software delivery to the customer.

    During the inevitable pain-points of moving to a more DevOps-centric process, the risk of siloed development can crop up again. You can often have the original agile team working together, with the security and operations additions still finding their way in the machine. No one is quite sure how to include them, what they should be doing and their overall objectives.

    DevOps does not work without clearly defined objectives, cross-functional onboarding and direct communication with all parties. There will be an adjustment period requiring careful change management but getting everyone on the same page with the enhancements DevOps functionality will bring is half the battle.

    Increasingly, DevOps is placing emphasis on security best practice as part of the process as well, demystifying that step and bridging the gap between the security team and everyone else. As I have said before, we still have a long way to go in empowering developers to code securely from the start, but the successful implementation of DevOps methodologies is an excellent foundation on which security skills can be built within the development team.

    Automation Isn’t Everything (and It’s Not the Most Secure)

    Another feature of DevOps methodology is, to a certain extent, the automation of the software development process. Continuous integration and continuous delivery (CI/CD) principles are the cornerstones of this concept, and as you can likely guess, very reliant on tools.

    Tools are awesome. They can bring unprecedented speed to the software delivery process, managing the code repository, testing, maintenance and storage elements with relatively seamless ease.

    However, while robots might take all our jobs and imprison us someday, they are definitely not there yet. Heavy reliance on tools and automation leaves a window wide open for errors. Scans and tests may not pick up everything, code may go unchecked and that presents enormous quality—not to mention security—issues down the track. An attacker only needs one back door to exploit to steal data, and forgoing the human element in quality and security control can have disastrous consequences.

    The happy medium is to ensure you have a balance of people and tools. Tools should serve as the assistants to a team you trust to deliver on project goals. You should:

    • Allocate enough time for people to become familiar with the chosen DevOps toolchain.
    • Focus on effective collaboration (and how the tools can support that).
    • Address any gaps in the process, whether they are skill/knowledge or tool-based.

    In short, don’t just tool up and hope for the best.

    DevOps Isn’t a Buzzword, It’s a Culture – Are you Growing Yours?

    Change management is tough at the best of times. Fear of the unknown can stop even the most brilliant team members from growing their skills and expanding their horizons.

    You see, merely saying “let’s do DevOps” and making the operations team move desks isn’t going to magically implement a successful process. Many will be confused, and long-serving members of the team will be left feeling disgruntled. Communication of expectations is crucial, as is walking the walk. DevOps represents a cultural movement just as much as a development methodology, and a team should live and breathe a cross-functional, collaborative mindset.

    What does a great DevOps culture look like?

    • Individuals are empowered to lend their expertise to a process, not just leaders.
    • Open, honest and respectful communication between teams.
    • Each person takes responsibility for the overall objective of building quality and security into the development process.
    • Everyone is on the same page with the definition of DevOps in the business, the roadmap and how/what/why of each person’s role.

    For years I have emphasized the importance of building positive security cultures in development teams, and DevOps is no different.

    The right tools, knowledge and support are imperative to achieving security best practice, seeing a downturn in discovered vulnerabilities and opening the team’s eyes to the importance of protecting our data. With DevOps, you must lay the cultural groundwork for positive change: Ensure everyone understands their role, value and expectations, the overall project goals and steps in the process.

    Have you mastered that? Great. Now, let’s shift the needle, dial up the security aspect and make DevSecOps the ultimate plan for software excellence.

    — Pieter Danhieux

  • Motorola Solutions: Driving a Thriving Security Culture

    Motorola Solutions: Driving a Thriving Security Culture

    It’s crunch time in the cybersecurity industry. For too long, many companies have remained unmoved by the increasing threat of cyberattacks, despite increased digitization of their products and services. Customer data is the new gold, and some organizations are leaving the door to their vault wide open.

    In saying that, secure development is complex and not without its challenges, especially at scale. In my experience, it is an uphill battle to win over developers on secure coding and best practices. In the mind of a busy programmer working to achieve strict delivery deadlines, security is not a priority over feature development and function—it is instead seen as a tedious task that interrupts their creative flow. However, if we are going to ready ourselves in the battle against those who seek to do harm, this culture needs to change.

    Marilyn Barrios is the senior cybersecurity training manager at Motorola Solutions, running the security training program for its team of more than 6,000 developers across the globe. Her goal is to ensure that those on the front lines of the company’s extensive software development are equipped with the knowledge, tools and ongoing training required to combat the growing global cybersecurity threat.

    To accomplish this, Barrios created an impressive internal security culture, one that thrived not only from a core skills perspective, but also in understanding its paramount importance in overall software quality. Her people-first, positive approach engaged the development team, created excitement about security and morphed into something far more powerful than a simple compliance exercise.

    “Ensuring that our products are secure is our highest priority. That’s why we’re working to create a culture of security-first thinking across the company—so people not only understand cybersecurity and why it is vital to maintaining a high standard of software quality, but are also excited to learn more,” she said.

    With such a large development team covering multiple facets of the business, insight into each individual’s security knowledge and current skill level could be elusive and difficult to collate. Barrios sought to streamline this process, working toward a holistic solution that would deliver key metrics and relevant training in the languages and frameworks that were actively being used in the business while remaining engaging enough to be revisited—even for more senior engineers.

    Marilyn and her team worked to implement an immersive, engaging training experience for their developers. Starting with a boot camp run by security superstar Jim Manico, the developers learned offensive coding techniques before playing in tournaments to test their defensive skills against the attacks they had just seen in action. This setup proved effective and eye-opening for the participants.

    “In really diving deep into how cyberattacks can be executed, the team saw how easy it was to do a lot of damage at the application level,” Barrios noted. “By then practicing how they can defend against these attacks, developers’ eyes were opened to how they can help if they keep security a priority in their work. They enjoyed the experience and it was also beneficial for them.”

    I was proud to see how well she and her team at Motorola Solutions executed a comprehensive, engaging and fun security training program that not only lifted security awareness IQ overall, but also helped to identify a new group of champions to keep the critical message of cybersecurity best practices thriving long-term within the organization.

    It was also interesting to learn that the eventual winner of the tournament did not start the program as the most experienced and security-aware developer. The boot camp was instrumental in rapidly upskilling the individual, and the gamified aspect of the training ensured a high level of engagement and information retention.

    “Our eventual tournament winner was so excited with the boot camp, and he was so engaged with the training tool. He practiced so much in a two-month period, improving so significantly, that he ended up winning the tournament,” Barrios said. “From there, he recruited even more champions, piqued their interest in security and helped them along to become advocates in their respective groups.”

    Barrios’ broader goal of creating a strong buzz that encourages an organic security culture to grow within the company is certainly on track.

    Gamified training, team events driven by tournament initiatives and the incentive to keep engaging with AppSec have resulted in something very positive: Developers not only are working to have a better understanding of security, but also actively seek to uphold company best practice initiatives day to day.

    Motorola Solutions saw measurable improvement when using tools and training compatible with the creative, problem-solving mindset of many developers, enjoying a training participation rate of more than 90%, with security accuracy increasing 24% across the global tournament that followed. Its internal security champion program has also seen immense support, growing by more than 1000% in the last 18 months. The company currently boasts 173 champions across its various product lines and will double that again over the next year. It has set a goal of at least one champion per scrum team—an initiative that holds incredible value in continuing momentum and spreading positive security influence across the organization.

    Driving a positive security culture takes time, planning and dedication, but alongside the right tools and training, Barrios’ advice is a sound reminder that clear goals and communication are powerful in achieving widespread support and change: “Always tie objectives to the ‘why.’ You should know why you’re trying to meet a goal or influence change; don’t just give a direction with no context.

    “For us, it’s easy: we make it personal. Motorola Solutions is responsible for delivering key communications over mission-critical infrastructure and devices for public safety and commercial enterprises. First responders, citizens and front-line workers alike are relying on this technology to be as secure as possible, so we emphasize the importance of learning best practices,” she said.

    With every other day seemingly bringing bad news about the latest large-scale data breach, it is refreshing to see an organization with a highly successful security program—one that can only get stronger as its developers continue to train and become the security superheroes we need to protect our digital world.

    — Pieter Danhieux

  • DevSecOps: Old Security Bugs Still Performing New Tricks

    DevSecOps: Old Security Bugs Still Performing New Tricks

    New Security Flaws Creep into Reliable Old Systems

    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 AUTHORITYSYSTEM 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.

    — Pieter Danhieux