asw148

Application Security Weekly Episode #148 – April 26, 2021

Subscribe to all of our shows and mailing list by visiting: https://securityweekly.com/subscribe

1. Deceptive Diffs From Subversive Submitters – 12:30 PM-01:00 PM

Announcements

  • Security Weekly listeners save $100 on their RSA Conference 2021 All Access Pass! RSA Conference will be a fully virtual experience from May 17th-20th, 2021. Security Weekly will be live streaming Monday-Thursday in the virtual broadcast alley, interviewing some of the top sponsors and speakers for the event. To register using our discount code, please visit https://securityweekly.com/rsac2021 [securityweekly.com] and use the code 5U1CYBER! We hope to “see” you there!

  • Do you want to stay in the loop on all things Security Weekly? Visit https://securityweekly.com/subscribe to subscribe on your favorite podcast catcher or our Youtube channel, sign up for our mailing list, join our Discord Server, and follow us on our newest live-streaming platform, Twitch!

Description

We start with the article about “Researchers Secretly Tried To Add Vulnerabilities to Linux Kernel, Ended Up Getting Banned” and explore its range of issues from ethics to securing huge, distributed software projects.
It’s hardly novel to point out that bad actors can attempt to introduce subtle and exploitable bugs. More generally, we’ve also seen impacts from package owners who have revoked their code, like NPM leftpad, or who transfer ownership to actors who later on abuse the package’s reputation, as we’ve seen in Chrome Plugins.
So, what could have been a better research focus? In the era of more pervasive fuzzing, how much should we continue to rely on people for security code review?

Read the research paper at https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf

For additional resources please visit:
Deceptive Diffs From Subversive Submitters – ASW #148 Featuring: John Kinsella (https://www.linkedin.com/in/jlkinsel), Mike Shema (https://www.linkedin.com/in/zombie). We start with the article about “Researchers Secretly Tried To Add Vulnerabilities to Linux Kernel, Ended Up Getting Banned” and explore its range of issues from ethics to securing huge, distributed software projects.

Read the research paper at https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf

For further details please visit:
https://securityweekly.com/asw148

Hosts

JohnKinsella

John Kinsella

@johnlkinsella

Chief Architect at Accurics

MikeShema

Mike Shema

@Codexatron

Product Security Lead at Square

2. Signal Aesthetics, AirDrop Privacy, Safety vs. Security, & Data Ordering Attacks – 01:00 PM-01:30 PM

Announcements

  • Our next technical training will be on May 6th at 11am ET exploring common misconfigurations of NGINX, the damage they could do, and how to avoid them! Next up, see how attackers gain access to endpoints and learn defensive strategies to protect against those attacks in our May 13th technical training also at 11am ET! Visit https://securityweekly.com/webcasts to register now! If you missed any of our previously recorded webcasts or technical trainings, they are available for your viewing pleasure at https://securityweekly.com/ondemand

Description

This week in the AppSec News: Signal points out parsing problems, privacy preserving improvements to AirDrop, Homebrew disclosure, WhatsApp workflows, adversarial data ordering for ML, & more!

Hosts

JohnKinsella

John Kinsella

@johnlkinsella

Chief Architect at Accurics

  1. Leveraging your Role as Technical Product/Project Manager to Improve Application Security – As we search for others to bring into our circle of securing the applications, many organizations now have “technical” project managers – a position that isn’t dev, sec, or ops, but nonetheless can help us think of security by how they prioritize the work we do
  2. How we think about safety vs security – Argo released their 50 page safety report, which includes one page on information security. Useful to read how safety is addressed in a methodological manner, compared to what usually happens in information/application/operational security.
  3. Looking at the security of a commercial phone hacking device – Cellebrite develops tools for governments to gather data from cell phones in their physical possession, more than likely without permission of the phone’s owner. Leaving politics aside, Signal happened to find some Cellebrite gear and performed some security analysis on the product. It looks pretty bad…
MikeShema

Mike Shema

@Codexatron

Product Security Lead at Square

  1. Homebrew Security Incident Disclosure – A clever RCE that took advantage of automation intended to make simple pull requests safe to automatically approved. The attack took advantage of a GitHub Action, showing the importance of understanding not only the impact of code changes on the artifact to be built, but also the tooling that builds those artifacts. It also put successful coordination into coordinated vulnerability disclosure. Read more of the researcher’s notes at https://blog.ryotak.me/post/homebrew-security-incident-en/
  2. Designing sockfuzzer, a network syscall fuzzer for XNU – Kernels are newsworthy favorites this week. We covered the “hypocrite commits” from UMN in this week’s discussion topic. Security millions of lines of ever-changing code requires more than just code reviews. Fuzzing has been demonstrably successful against the Linux Kernel, as well as large projects like Chrome and smaller projects with large surface areas like video codecs and image libraries. Now more fuzzing is coming to the macOS kernel. We’ll expect to see security benefits — in terms of finding many flaws — soon within the family of macOS, iOS, and tvOS.
  3. New Warning For WhatsApp Users Over Account Suspension ‘Hack’ – Here’s a good reminder to two common themes we return to: there’s more to security than memory safety and availability is an important peer to confidentiality and integrity. As app security improves the implementation side of things with language choices like Rust, fuzzing, and better compiler defaults, appsec practitioners should continue to broaden their threat models into how workflows can be abused and misused. These are the kinds of “business logic” flaws that deserve a richer discussion than just saying business logic.
  4. 7 most common ways to fail at DevSecOps – Nothing too earth-shattering or insightful on this list, but it does tie into this week’s theme of healthy collaboration between security and DevOps. Modern appsec should be very cognizant of the need to communicate business value as much as it should under the business behind the products DevOps teams are working on. And here at ASW, we’ll always push against the pitfall of being too risk averse if you’re using overly simplified threat models or, even worse, using threat models grounded in some sort of security purity vs. a reasoned evaluation of the context around a feature.
    It’s a short article that goes hand in hand with a similarly brief article on avoiding these failures by closing the gaps in your security and DevOps practices. Check it out at https://devops.com/devsecops-practices-gap-assessment/
  5. AirDrop bugs expose Apple users’ email addresses, phone numbers – Protocols are hard to design well and fun to analyze. This research into AirDrop is a good way to discuss threat models — when and in what situations are close-proximity attacks of more concern — and a well-written example of analyzing the effectiveness of privacy safeguards within a protocol. In this case, the researchers demonstrate attention to security, engineering, and UX by recommending improvements that can preserve privacy without degrading the usability of the feature — something that security and DevOps collaborations should strive for.

    Check out the research paper at https://www.usenix.org/system/files/sec21fall-heinrich.pdf

  6. Data Ordering Attacks – Cryptographers have long known and appreciated the need for secure random number generators. This paper looks at how training models can be subverted by reordering the data used to train them. It’s an intriguing threat model where the adversary need not introduce their own data nor corrupt existing data, but merely order the training data in a way that introduces biases. Plus, “stochastic gradient descent” would be a great name for a cyberpunk synthwave band.

    Check out the research paper at https://arxiv.org/abs/2104.09667