1. Doing Application Security Right – 12:30 PM-01:00 PM
Don’t miss any of your favorite Security Weekly content! Visit https://securityweekly.com/subscribe to subscribe to any of our podcast feeds and have all new episodes downloaded right to your phone! You can also join our mailing list, Discord server, and follow us on social media & our streaming platforms!
Cybersecurity is a large and often complex domain, traditionally focused on the infrastructure and general information security, with little or no attention to Application Security. Security providers usually tack-on AppSec services to their existing menu of offering without understanding the domain, and their team of professionals have little or no experience with software development or inner workings of modern application architectures. As the world turns Digital at a rapid pace accelerated by the recent pandemic, applications become common place in our lives, providing attackers more opportunities to exploit these poorly protected applications. As such, it is important to know what is actually required to build and run software securely, and how to do application security right.
Farshad Abasi – Founder and Chief Security Officer at Forward Security
Farshad Abasi is an innovative technologist with over twenty four years of experience in software design and development, network and system architecture, cybersecurity, management, and technical instruction. With a keen interest in security from the start, he has become an expert in that aspect of computing and communication over the last eighteen years. He started Forward Security in 2018, with a mission to provide world class information security services, particularly in the Application and Cloud security domains. Prior to creating Forward, he was a senior member of HSBC Group’s IT Security team with the most recent positions being the Principal Global Security Architect, and Head of IT Security of the Canadian division. Farshad is continuing an eighteen year stint as an instructor at BCIT where he shares his passion for information and network security, helping others build a career in this exciting field. He is also the security correspondent for CFAX radio, BSides Vancouver/MARS board member, Vancouver OWASP chapter lead, a CISSP designate, and a UBC CS alumnus.
Co-founder & CTO at Cysense
Security Partner at Square
2. Dirty Pipe, AutoWarp Vuln in Azure, TLStorm Hits UPS Devices, Car Hacking – 01:00 PM-01:30 PM
Do you have a specific guest or topic that you want us to cover on one of the shows? Submit your suggestions for guests by visiting https://securityweekly.com/guests and completing the form! We review suggestions monthly and will reach out to you once reviewed!
The Dirty Pipe Vulnerability – We have a new named vuln that “allows overwriting data in arbitrary read-only files”, which leads to “privilege escalation because unprivileged processes can inject code into root processes.”
It’s quite a fun read that walks through a very long journey to uncover a curious bug from log files being sent to a pipe that ultimately revealed a serious security flaw — and a one-line fix (well, technically the same line in two places) to correct an uninitialized variable.
As the article notes, the name is a riff on the “Dirty Cow” vuln from 2016 (https://dirtycow.ninja).
What’s up with in-the-wild exploits? Plus, what we’re doing about it. – This article shows how attack surfaces change over time for attackers motivated by targeting software with huge user populations. After several decades, we’ve finally moved on from yet another critical Flash vuln. Unfortunately, we’re still dependent on software and we’re still humans writing software and there’s still bugs in that software. What this article highlights is the shift from deprecated apps like Flash to other ubiquitous software like Chrome.
Zero-Click Flaws in Widely Used UPS Devices Threaten Critical Infratructure – At first this looks like a vuln in very specific OT (UPS devices used within critical infrastructure), but poking at some of the details reveals lessons for secure development and the supply chain. The flaw boils down to an app that ignored error messages from the third-party TLS library it uses. Like lots of software, the TLS library (NanoSSL) provided cautions against ignoring error messages. Notably, it also boasted of having robust ASN.1 parsing and secure string handling with “‘length strings’ instead of more common ‘C-length strings'” and they include fuzzing as part of their SDLC. [^1]
But here we see secure code being used insecurely. As a consequence of ignoring TLS errors, the UPS devices could be tricked into loading malicious firmware — essentially putting them under an attacker’s control. So we can also add a lack of more robust firmware signing to the missed opportunities here for secure software.
The TLStorm article is at https://www.armis.com/research/tlstorm/
[^1] https://www.mocana.com/press-releases/mocana-nanossl-customers-not-vulnerable-ssl-attack-revealed-black-hat — skipping over the marketing language of this article, it’s good to know that fuzzing and secure string handling was considered part of the library’s development.
Telegram Harm Reduction for Users in Russia and Ukraine – Sure, computers are binary, but appsec rarely is. One of the most common phrases in threat modeling and appsec commentary is “it depends”. In other words, context is important for how an app is used, who is using that app, and how those users might be targeted. This is a good example that borrows from the concept of harm reduction taken from public health practices that aim to help drug users. Don’t get caught up in any metaphors here. In this appsec example, the idea is that users may not have good choices available to them (such as widespread use of Signal among their peers) and therefore educate those users on how to use a messaging platform like Telegram more safely. For the appsec and DevOps side of things, understanding the threats described in an article like this is a good step towards building more secure features within an app — something just as important as technical basics like making decisions to avoid entire attack classes (such as using memory-safe languages).