The late cybersecurity luminary Dan Kaminsky is known for a lot of great research and his ability to explain it in plain English. But what his friend, collaborator, and company co-founder Michael Tiffany admired most about Kaminsky was his drive to scale positive impacts in security.
“As an inventor he was very much an engineer, meaning that he cared not just about how good his ideas were on some platonic level of the world of ideas, but how they actually made contact with reality and succeeded at making the world a better place,” says Tiffany, who co-founded Human Security (formerly WhiteOps) with Kaminsky as a way to scale that impact against bot-led Internet fraud. “It’s not just about being right. It’s about connecting your innovations with the people who need it in a way that can actually scale really widely.”
To honor Kaminsky’s work for the common good — the kind that spanned far beyond his own commercial interests — Tiffany and the Human team wanted to find a way to support the next generation of security researchers who have a flair for being force multipliers in cybersecurity improvement.
This was the impetus for the creation of the Dan Kaminsky Fellowship, a program that will fund a new fellow each year to work on open source projects that will hopefully make the world a more secure place. Unlike grants or prize programs, the Dan Kaminsky Fellowship is a paid position that gives the researcher full employment support and 12 months of breathing room to shift their passion projects from weekend and moonlight work into a full-time job, Tiffany says.
“I found that there are still barriers to getting that kind of focus on the part of grant recipients because if you’re used to working for a living, you might find this is the first time you’ve ever had to get health insurance on your own, for instance,” he says. “We thought this is a place where we could have an outsize impact by finding people who are doing great work and wrapping them in a support system with salary, an HR department, tax withholdings, benefits, and a light support infrastructure.”
In this inaugural year of the fellowship, this support was awarded to Jonathan Leitschuh.
Most recently a senior security software engineer for the security team at Gradle, Leitschuh has been building a name for himself in recent years by hunting down and fixing security issues in open source projects, particularly in Apache Maven projects. One of the highlights of his work is not only his creation of a way to generate bulk pull requests against Git repositories in order to fix security vulnerabilities, but also his coordination with contacts at GitHub to get buy-in to make important Maven project fixes at scale without tripping up on their terms of service.
“What really struck me with Jonathan’s work is that he, too, is clearly looking for ways to really scale impact, and I was amused by the fact that one of his mechanisms for achieving that was by writing a bot as a force for good,” says Tiffany. “I wasn’t beyond the ironic charm of our company — a legendary bot fighter — actually … funding some good bots.”
Dark Reading recently had a discussion with Leitschuh to better understand his methods, his work, and what he hopes to explore in the coming year. Here are some highlights from that Q&A.
Why He’s So Invested in Chasing Down Open Source Vulnerabilities
Leitschuh: I have ADHD, and sometimes it’s like “Oh, hey, look, a squirrel!” It is something that I sometimes go and chase. It’s like, “Ooh, look, this vulnerability looks interesting. I want to learn more about it.” Then, of course, when I learn more about it, I go and say, “OK, I wonder what projects have this vulnerability?”
Then I inch down this rabbit hole of, “Good Lord, this vulnerability exists in thousands of projects.” I spent a solid chunk of six months chasing down a single vulnerability. It crossed a massive number of projects.
On His First Big Moment Moving the Needle on Open Source Security
Leitschuh: The first big bit of security research that I chased down was this vulnerability where Maven and Gradle build files were resolving their dependencies over HTTP instead of HTTPS. It was this industrywide security vulnerability impacting the ecosystem supply chain.
After doing all this research, I watched a couple of Dan’s talks and thought about some of the things that Dan pushed for. One I really appreciated was, “The user’s not stupid. We need to build systems that make it easier for them to not shoot themselves in the foot.” And also, “The user’s not going to know they have a vulnerability unless you make it so they have to fix it.”
So one of the things that I finally realized, after doing this very long bit of security research around the use of HTTP to resolve dependencies, was that most of the cases of this vulnerability were because of specific servers that were still serving their content over HTTP instead of HTTPS.
So I went and reached out to [owners of] the servers and said, “Hey, you’re culpable. You’re part of the chain that allows this vulnerability to even exist. Why don’t we just shut that off? Why don’t we just kill that? It will break a lot of things, but you’ll force a lot of people to go fix this vulnerability.”
I got them to get on board with this thing, and they all moved forward and actually said, “Yeah, let’s go fix this.”
And so on Jan. 15, 2020, they shut off the use of HTTP and supported only supporting HTTPS. It broke a bunch of software. It broke a bunch of builds. But it forced the industry to move forward from a security perspective.
How He Built a Bot for Fixing Lingering Maven Problems at Scale
Leitschuh: Even though I’d done that work, this vulnerability still existed where other people were still not reliant on those big three servers, but they were reliant on other artifact servers. I’m like, “How do you get that last bit of work done?” So I said, “Well, I know where all the projects are that are vulnerable.” I wrote a CodeQL query that said, “Here are all the projects that are vulnerable.” So I had a list and I’m like, “Why don’t I just fix it?” But it was thousands of projects. I can’t do this by hand, every single one. But I could see the path. This was a cookie-cutter enough vulnerability that you can just fix with a bot. I figured, “Why not?”
I have some really great connections with the people at GitHub. I said, “I want to do this.” Instead of saying, “Well, no, that’s not allowed by our terms of service,” I just got people at GitHub saying, “That’s amazing. Let’s go do this.”
And when I did my Bulk Security Pull Request Generation, I also live-streamed it. So I pulled people in from GitHub, co-workers of mine, friends are in this call, and I’m live-streaming this whole thing. They tell me later, “We let our team know that this is coming so that when you inevitably get reported for being a spammer or something like that, our conduct team knows ahead of time that this is Jonathan trying to improve the industry a little bit.”
I chase these stupid, crazy ideas, but the support system that I’ve received around that has been spectacular.
On What’s Next With His Work Through Fellowship Support
Leitschuh: One of the things that’s really hard in software is making changes to code, especially code that’s written in a lot of different ways and may have different indentation and formatting and stuff like that. It’s not an easy problem. So I’ve actually partnered with a former co-worker of mine who went off and started a company. It’s this project called OpenRewrite. His company is called Moderne. His name is Jonathan Schneider. He’s developed this tool that lets you do code refactoring at scale. He was mostly focused on a different problem that wasn’t really security. I’m like, “This is perfect for solving a security problem.”
There are very common security problems that are duplicated, and the root cause of some of these things are [a developer] posts an answer [to] a question on Stack Overflow like, “How do I do this thing?” And the top answer to that Stack Overflow question is a solution, but it’s a vulnerable solution. You’ll go and look at open source, and you’ll see that same code has been reproduced and pasted, copy-pasted, a ton of times across open source. So these common vulnerabilities can proliferate [in] open source. But how do you go and fix those things?
I’ve been taking my knowledge of security vulnerabilities and their ability to rewrite that actual code and collaborating together to try to come up with a set of vulnerabilities that are good candidates for this kind of automated fixes.
There’s a lot of low-hanging fruit. A lot of people don’t want to deal with it because it’s like, “Oh, that’s not interesting. Oh, that’s not cool.” But it’s actually really impactful. There’s certain vulnerabilities that fall in that category. I’m trying to figure out how we can chase those specific ones down and eliminate them. And then on top of that, if I get the opportunity, there are certain vulnerabilities that are low-hanging fruit, but they’re low-hanging fruit because the code itself is vulnerable and its root cause is deeper.
There’s this trend that you’ll see in security where there are all these scanning tools for finding security vulnerabilities, like external entity processing [XXE]; there’s all these scanning tools to find that vulnerability in Java, Python, [and] C++. The root cause of those vulnerabilities is really the libraries themselves, and the underlying infrastructure that these libraries are depending on are themselves vulnerable. Some of the things that I’ve been trying to chase down, too, is how to fix this from a root cause perspective.
Source: www.darkreading.com