For this week’s “In the News”, research an article dealing with how secure code development practices (or lack thereof) affected a major software project; was the project more or less successful as a result?
Reader Interactions
Comments
Leave a Reply
You must be logged in to post a comment.
The unfamous sensitive data exposure of Cloudbleed of 2017 was made possible due to Google’s project found an issue in Cloudflare’s edge server. This made it possible to dump the potentially sensitive data through a cached search engine. Cloudflare acknowledged the leak during the ate 2016 through a leaked private key by Cloudflare. The platform was built on the assumption of the secure TLS channel. Since the founding of the bug, it was triggered around 1,242,071 times. It was later identified that Cloudflare features using the HTML parser chain were causing the leak. As a result, a global response team was formed, and Google and other search engine removed any cached HTTP responses. The industry standard time allowed to deploy a fix for a bug like this is usually three months; we were finished globally in under 7 hours with an initial mitigation in 47 minutes. The bug was serious because the leaked memory could contain private information and because search engines had cached it. We have also not discovered any evidence of malicious exploits of the bug or other reports of its existence.
References
Cumming. J. (2017). Incident report in a memory leak caused by Cloudflare parser bug. The Cloudflare blog. Retrieved from https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/
Susanto. A. (2020). Real Life Examples if Web Vulnerabilities (OWASP 10). Retrieved from https://www.horangi.com/blog/real-life-examples-of-web-vulnerabilities
Hello Rushi,
Great post and links!
The article on “Real Life Examples of Web Vulnerabilities” is cool and informative.
According to the story by Cloudflare, that bug was serious enough that the leaked memory could have contained PII and it was also cached by search engines. Fortunately, they have not found any evidence of malicious exploits of the bug for now and have not heard of any more issues.
Software developers must integrate comprehensive information security “best practices” throughout an application’s lifecycle. If they do not, it can jeopardize national security by increasing the threat landscape of high-value networks and sensitive data. Sadly, many of today’s technology manufacturers prefer to quickly get a product to market over cybersecurity. There has always been a culture of “deploy now, patch later” and this shifts the liability of their vulnerable software onto consumers through EULAs.
“Software Security is National Security: Why the U.S. Must Replace Irresponsible Practices with a Culture of Institutionalized Security” explores the systemic problems in software security. I found this whitepaper while searching for a story this week. It is quite interesting, contains a lot of great information, and lines up with this week’s class.
The paper discusses these major issues:
• Systemic problems in the software development landscape
• Need for a cultural Renaissance in software security
• Guidelines and frameworks to improve software security
• Recommendations to improve negligent software development
https://icitech.org/wp-content/uploads/2019/04/ICIT-Brief-Software-Security-is-National-Security-2.pdf
https://www.securecoding.com/blog/owasp-secure-coding-checklist/
Vincent, your article is enlightening, it touches at the very heart of security issues in today’s organisations. I will quote an excerpt from you post “Sadly, many of today’s technology manufacturers prefer to quickly get a product to market over cybersecurity.” Many IT Security professionals have been faced with this huddle, profits supercede everything else.
This is definitely something that happens frequently. Many organizations have recently begun adding cybersecurity professionals to their boards. I wonder if having more cybersecurity savvy board members will alleviate some of the “deploy now, patch later” mentality.
Last month, Google issued a routine update for its Chrome browser, which just so happened to include 14 security issues, including a 0-day bug that was actively being exploited. This bug affects the V8 open-source and Javascript engines. The attacker who found these exploits had been using them in small attacks on targets in Eastern Europe and the Middle East. Google had to rush and update the browser to patch these exploits in order to stop these attacks from occurring, of which this is the 7th time this year a 0-day had to be patched. While Chrome is an established browser that the majority of computer users utilize on a daily basis and have the man power to patch these exploits fast, it would be better to have proper code review to make sure these 0-days do not make it to the public builds.
https://thehackernews.com/2021/06/new-chrome-0-day-bug-under-active.html
Hello Krish!
This goes to show you how pervasive these attacks are. Networks private and public are subject to a daily barrage of attacks relentlessly looking for a way in. We have to find and patch all of the holes; they only need to find one. Think of it as job security!
Great concise post and link!
You would think that a company like Google would be more on top of running strong code-review, especially after the first 6 0-days! I wonder if pair programming would alleviate some of the issues that they are running into.
Hello Krish!
This goes to show you how pervasive these attacks are. Networks private and public are subject to a daily barrage of attacks relentlessly looking for a way in. We have to find and patch all of the holes; they only need to find one. Think of it as job security!
Great concise post and link!
Wrong place
Agreed! SDLC needs to consider information security more closely! DevSecOps is a critical function that will encourage the implementation of code review and integrity tools to be implemented throughout the process.
The SolarWinds hack of 2020 demonstrates the importance of secure code development. With hackers being able to access SolarWinds code and embed malicious code within it it goes to show why it’s key to implement tools to scan code EARLY in the SDLC process. Proprietary code is falsely thought to be more secure than open source code but this recent hack proves that no code is impenetrable. Security should start with the developer and a thorough scanning of Open Source code, proprietary code, containers and infrastructure as code. This allows an organization to “identify, prioritize, fix and monitor vulnerabilities.” Solarwinds became compromised in 2019 when their their development environment was hacked and threat actors were able to embed the malicious code. This code injected backdoors, dubbed “Sunspot” into Orion, a tool to manage internal networks. This tool was used by many Fortune 500 firms. Updates pushed by SolarWinds to clients included the malicious code. According to Crowdstrike, ” Sunspot was written to be able to detect when it was installed on a SolarWinds developer system, and to lie in wait until specific Orion source code files were accessed by developers. This allowed the intruders to “replace source code files during the build process, before compilation,” The code also bypassed logs and checks to avoid detection.
https://www.theguardian.com/technology/2020/dec/15/orion-hack-solar-winds-explained-us-treasury-commerce-department
https://krebsonsecurity.com/2021/01/solarwinds-what-hit-us-could-hit-others/
https://snyk.io/blog/solarwinds-orion-security-breach-a-shift-in-the-software-supply-chain-paradigm/
Vanessa,
This is a great article, regardless of whether a company uses proprietary code, they should still go through a tight security assessment and als has to b checked and monitored regularly for vulns and patches.
So yes, agree that “Security should start with the developer and a thorough scanning of Open Source code, proprietary code, containers and infrastructure as code.”
Hi Vanessa,
Great example! SolarWinds definitely need secure design principles in place especially for a company their size. They should’ve also created better processes to protect their source code. Due to their broken process, none of their products can be trusted. How can companies work with a vendor like SolarWinds when their “foxes” /patches also are the problem.
In January, a buffer overflow vulnerability was found in Libcrypt, a cryptographic library from gnupg. The programmer who wrote the code included some input validation but made a mistake/incorrect assumption which left the code vulnerable to buffer overflows. Mistakes are going to happen – that’s just part of being human! However, this type of error could be caught and fixed earlier if the code is reviewed by a different party during the testing phase.
https://bugs.chromium.org/p/project-zero/issues/detail?id=2145
New Top 20 Secure-Coding List Positions PLCs as Plant ‘Bodyguards’
Best practices guide encompasses integrity, hardening, resilience, and monitoring of PLCs in industrial networks.
Programmable logic controllers (PLCs) traditionally have been considered inherently insecure. But a new security initiative that outlines 20 best practices for coding the industrial computing device aims to reimagine the PLC as the last line of cyber defense in an industrial process.
A group of cybersecurity experts and automation engineers has created an open source guide with 20 recommendations for configuring PLCs for resilience in case of a security incident or misconfiguration on the industrial network. The so-called PLC Security Top 20 List — hosted by the ISA (International Society of Automation) Global Cybersecurity Alliance — will be officially released tomorrow, June 15, for automation engineers to use when programming PLCs to perform physical processes, such as controlling the temperature of fluids and opening and closing valves or gates in a plant or facility.
https://newsakmi.com/news/tech-news/cyber-security/new-top-20-secure-coding-list-positions-plcs-as-plant-bodyguards/
‘Mass Ransomware Hack Used IT Software Flaws, Researchers Say’
The IT management software(VSA) produced by Kaseya Ltd recently suffered a mass ransomware attack by REvil. The Dutch Institute for Vulnerability Disclosure found multiple vulnerabilities in Kaseya’s software and was working with them to patch them up when the ransomware attack happened. Ultimately REVil got to them before their final sprint and exploited the vulnerabilities before customers were able to update the patch.
REvil was behind many large ransomware attacks this past year and their hackers are known to be highly skilled. They were able to use an attack chain, leveraging multiple vulnerabilities present in the system, and is considered a ‘sophisticated weaponized attack’. This was not just one simple zero-day, they were also widely successful because of their clever targeting. Kaseya is the tool normally used for patching and IT Support/Recovery, what do we do if our protectors are attacked? It was a brilliant move on their part, attacking the supply chain. This shows how important it is to have security built into each sprint and not wait for the vulnerabilities to be disclosed. No one is safe, not including the people providing our security protection tools, we must proactively build counter defenses before even deploying the product into production.
https://www.supplychainbrain.com/articles/33362-mass-ransomware-hack-used-it-software-flaws-researchers-say