 Welcome to this virtual voting village talk, Vulnerability Disclosures for Voting Systems, a deep dive into vulnerability disclosure programs among the most popular voting system vendors. Thanks for coming. I wish I could be there in Vegas with you, but alas, the COVID weather is just too severe, so couldn't make it this year. Next year, for sure, right? So yeah, I'm Todd Beardsley. I am the director of research at Rapid7, and I deal with vulnerability disclosure pretty regularly. And I also, incidentally, care about election security and election integrity. And because of that, I'm also an election judge here in Travis County, Texas. If you want to find me or look up my stuff, you, a great starting point is keybase.io slash Todd Be. All my Twitter's and all my stuff is there, so check it out there. But enough about me, on to the voting machines that we're all interested in hacking, I guess. All right, I'm up in the corner now. I'll be here for most of the presentation just to stay out of your way. First off, let's blast through some terms that I am likely to use all of the time. They are Coordinated Vulnerability Disclosure or CBD. This is the process by which I typically disclose vulnerabilities. Typically it starts with a researcher, almost always who is not me. Occasionally I do my own roles, but mostly these days I help other people disclose vulnerabilities. And this, for me, this is all about getting the vendor and the researcher and any other interested parties, maybe a regulatory agency or somebody like that, all on the same page, all ready to go, all agreeing on what the vulnerability is, severity, descriptions, mitigations, fixes, all that stuff. That whole thing from beginning and end, from discovery to eventual public disclosure, that's CBD. So if I say CBD, that's what I mean. Also, I use another acronym, VDP, a Vulnerability Disclosure Program. A Vulnerability Disclosure Program is pretty much, in my opinion, it is pretty much anything where you are a vendor of software, which is to say all companies and most organizations, you have some kind of software product. It might be embedded, it might be a typical app on a phone, it might be a typical program, it might be server side, it might be your website, it might be your backend, it might be anything, right? Basically what we're looking for in a VDP is some way to contact you and let you know about this vulnerability. I don't super care about the details of it, just if you have a VDP, great. And you're in rare company, if you do. And then finally, we have bug bounty programs. I talk about it a little bit, nobody calls them BBs. This is something we don't acronym, I don't know why. But a bug bounty program is basically like a VDP, except there's usually money involved, not always, sometimes it's just like for like Kudos and Karma or whatever. Almost always there's some kind of more formal NDA in place, usually restricting the reporter of the vulnerability from talking about it until the receiver, the bug bounty runner, does a thing. Either they fix it, very occasionally they, I would say occasionally, not very occasionally anymore. Occasionally they have like a timeout procedure, so if so much time has passed, then you're free to publish. But yeah, so that is the deal with bug bounties. So actually finding VDPs in the wild is not terribly hard. You know, I look at a few things, I look at Bug Crowd, Hacker One, and Disclose IO. I bring out Bug Crowd and Hacker One because they're bug bounty programs and it's in their interest to really let you know that such and such a company has a bug bounty program, which is a species of VDP. It's not the only kind of VDP, but it's a species of it. Disclose IO and Bug Crowd are like this and Disclose IO runs a pretty nice community sorted directory of vulnerability disclosure programs, right? I also look for the security.txt file that should be on a given companies or product, even websites. So like let's say you work at Acme Corp and your website is acmecorp.com. You would have a security.txt in acmecorp.com slash dot well dash known slash security.txt. You can learn a lot about this at securitytxt.org. It is a great way to tell people and it's like, well, let me back up. It's a great way to tell people about your vulnerability disclosure program, what the policy is, who to contact, a PTP key, languages, all kind of stuff can go in there. But the minimum is like some kind of contact information. I look for that basically second these days. I'm usually disappointed. Sometimes I come across one. And then finally, if those don't pan out, I Google to work around, right? For vulnerability, for the word disclosure, for the word security and whatever the organization or the product name is. Typically, if all of these fail, this tends to succeed. It's a very jargony sort of business we're in with vulnerability disclosure. So these words all together, almost always first page, great SEO, right? So if you are running one and people don't know where it is, make sure that this Google doc works and people will find it. If all of this fails, I kind of have to assume that you don't have a vulnerability disclosure program. That might not be true. And there's certainly other ways to advertise VDPs. But if it's not one of these five things basically, it is effectively invisible to certainly me and I would say most people who are in the business of vulnerability disclosure. In my business, I mean charity, almost always. Bug bounty programs are a little bit special and they tend to have their own thing. But again, and it's totally possible to run a bug bounty program without bug crowd or hacker one for sure. But if you're running your own homegrown bug bounty program and you're not hitting that Google doc or not hitting that secure that text, this is an easy problem to solve. So let's take a look at the Fortune 500 just for context. This is not, you know, none of these voting system manufacturers are in the Fortune 500, but we can take a look at the Fortune 500 and see what's going on there. Like kind of just a level set, like how common are VDPs out in the real world? You know, this is the world of name brands. You know, the most successful and highest revenue companies, lots of tech companies, lots of manufacturing companies, lots of everything, right, in the Fortune 500. Back in March, I ran around and counted all of these using exactly that methodology I just talked about. And you can read that report if you like. It's on rapid seven. If you just do like rapid seven ICER, you'll find it's the industry cyber exposure report. And if that's a person, I would ask for people to guess how many of the Fortune 500 have a VDP. And then I would chortle and say, you're wrong because it's actually this many. It's just about 20%, almost a hundred of the Fortune 500 have a VDP. Now they're not all in the top 100. Top 100 is overrepresented. Fortune 100 has about 40% of these and then the rest are kind of scattered throughout the remaining 400. But that like gives us an idea of like, well, how common are these, right? And I will say that on a given, a very successful company, about 20% have an active, findable VDP today. So how do I pick voting machines or I'm sorry, voting system manufacturer as well? I look at the EAC or the US Election Assistance Commission. They run a program that certifies vendors in this space. And one quick caveat before I talk about those, not every vendor is certified by the EAC and not every EAC certified vendors in all of the states, right? Or by state, I mean locality. So which ones are they? Well, they're these ones. There's Avante, Clear Ballot, Dominion Voting, ESSNS, Heart Interactive Microvote, Smartmatic, Unison and Voting Works. Those are the nine vendors that participate with the EAC, get their stuff certified. There's mountains of documentation on the EAC and this is not an EAC talk, so I'll just go by there. I'll just stop there. But like these are the nine companies that I'm looking at to see like who has vulnerability disclosure program. And as I mentioned before, quick caveat, this is where any of these companies operate today. By today, I mean, I think this survey was for the last election, the 2020 presidential election. So you can see that like, not even every, like there are a few states where it's 100% EAC certified voting machines. Some states have none. Some of them are rather large, like California and New York and Florida. All of the decision-making on what voting systems a given locality uses, that tends to evolve down to the county. But if you're in the voting village, you probably know that. So moving on from there. So among the VDPs, which are EAC certified? How many of them have some kind of VDP? How many of them are welcoming of vulnerability information on their products that are installed and people cast votes on? Or are used to tabulate votes or anything like that? Any election system can deal. What do you think? Well, you are right. Some of you, it is better than the Fortune 500. It is about 55% or 509. Have some kind of VDP. So good job. Good job, guys. We're doing better than we were even a year ago. Most of these are very new. And so just to remind you, 55% of voting system manufacturers have a VDP, about 20% of the Fortune 500 have a VDP. And so that is better. It is greater than. So good job, guys. For the next section, I want to kind of dive. This is the deep dive part. I want to dive deep onto these VDPs. So I read all of them, so you don't have to. And first and foremost, let's just knock out the ones that don't have any VDP at all. That is Avante, Microvote, Smartmatic, and VotingWorks. Guys, get on the stick there. But of the rest, all of these do have some kind of VDP. But not all VDPs are created equal, right? Of those that have a VDP, some of them don't actually cover the voting machines and customer implementations. So that knocks out Heart Inner Civic and Unison. So if you recall from last year at Black Hat and Def Con Time, I know that some of these vendors said like, yes, we have a VDP and we are anxious to work with researchers. Well, not so fast. These two companies in particular, Heart Inner Civic and Unison, their Voluntary Disclosure Program only covers their own website. And so great that they have one, but not so great that they have a written policy that says that their voting machines and any customer implementations are off limits, which is weird. It's kind of not a VDP anymore. But hey, you have a VDP, so wonderful. Of those that have a VDP that do cover customer implementations who has a safe harbor policy, well, it's not ClearBallot. ClearBallot is a little weird. They do have a place to report vulnerabilities. They publish an email address and they talk about their security a lot, but they don't actually seem to have any written policy. At least I couldn't find one. And if you know somebody at ClearBallot, reach out to me. I'd love to be able to find it. If it exists, it's invisible. So you're welcome to report vulnerability to them, but it's like unclear how they'll take it, which is fine, right? I'm glad they have some way of doing it, I guess. So ESNS and Dominion are the only two EAC certified voting system manufacturers that actually offer a clear, unambiguous, safe harbor for researchers and hackers in their vulnerability disclosure program. So yay, congratulations guys, you did it. ESNS and Dominion, I do believe their heart is in the right place. They're a pretty great place to report vulnerabilities. Incidentally, between ESNS and Dominion, you're looking at most of the voting machines in America, including in those areas that aren't required to have EAC certified voting machines. They still use them. They may be like back a rev, or they may just use them and not bother to tell the EAC because hands off my local government, you big federal nasties, or whatever reason, right? So it's certainly possible to run into a voting system from one of the other of these companies in a locality that EAC doesn't know about. So if you find vulnerabilities there, you are at smooth sailing, good job, and let them know because they wanna hear about it. But of all the other companies, don't give up. If you're a researcher or hacker or an academic and you find some kind of vulnerability involving one of these systems, I mean, it doesn't hurt to try. I wouldn't say just sit on it because that doesn't help anyone, right? And so this is my opinion anyway. Some people are real sketch about trying to report vulnerabilities to a place that doesn't have a clear and concise and unambiguous safe harbor provision for hackers. So these companies are less likely to get decent vulnerability intelligence from good Samaritans out on the internet than ESNS and Dominion. But it doesn't mean that you have to be that way, right? Like it is, of course, it's all up to your own risk tolerance, very similar to traveling to Las Vegas during COVID. It's up to you and it's up to like how you deal with it. But basically like if you have a vulnerability on a voting system manufacturer that's not on that list, or which is on that list, but their terms are like real restrictive, or they might be on the list. Like you found an issue, but you're not super sure what it's for. Like maybe you found some kind of SQL injection bug and some, you know, in like an ePoll book that's online or something like that, right? Like it's not directly a voting, it's not like a voting machine compromise, but it's a backend system compromise or like a maybe a mill to where or a front end for some county, like it may be run by one of these companies. These companies don't just produce voting machines, as you know, they often do the end to end management of the voting machines, the ballot box, the ePoll books, the collection, all of this stuff, right? They may be all up in that business. If you find a vulnerability in a candidate's website or in something in their infrastructure or in their campaign, what do you do? Or if it's like in a general political party issue, like as we all know, political parties are not immune to hackery and are certainly not immune to like not patching something. So if it's a political party or PAC, what do you do? Well, I'm here to tell you, there is one stop shop these days. I used to have a long, complicated answer for this, but now I have a very short and terse answer and it's SZA. SZA is pronounced not like pizza, by the way, but it's SZA. It's a cybersecurity and infrastructure security agencies, so secure the name twice was secure. I would say that like in all cases, if you see something, say something, SZA is generally pretty good about this. They have some really talented people there still and continue to be like pretty responsive. If you, yeah, so if you're not comfortable with interacting with SZA for whatever reason, you should know that as far as I know, they've never gone after anyone. They've never hassled anybody. They've never like turned around and ratted anybody out to the DOJ or anything like that. They've always been on the up and up and they are sincere in wanting to know about your vulnerabilities to fix them. And they are specifically excluded. This whole vulnerability intelligence gathering function that they have, they're excluded from the vulnerability equities program if you've heard of that and are worried about that. They're excluded from that. So spooks and spies will not use your vulnerability in the meantime, unless they're doing something like super duper illegal like spying on SZA, which that never happens, right? There's no such thing as interagency conflict, but they're a great backstop for basically anything related to civilian government, including these issues. So I urge you get in touch with SZA and they will take care of you. If you have a bad experience with SZA, let me know and I will, I don't know, be your champion and your white knight, I guess. I just want to take a moment to talk about the R words and that is reasonable or responsible disclosure. I try to use reasonable disclosure as a term, but it's just not taken off. Let's talk just a little bit about responsibility. Now that we've talked about who has a VDP, maybe you run into a situation where you're not comfortable with the VDP or you don't find a VDP or something like that, what do you do then, right? So the rest of this talk, I'm almost at the end here because these are all real short talks, rest of this talk is just pro tips, just a couple. Grab bag of pro tips. So first off, timing considerations. Nobody does anything without a deadline. If you report a vulnerability and don't say you're gonna do something in a certain amount of time, I guarantee you, no one will do anything with it. They may reply, they may say, oh, thank you for the thing and you'll never hear from them again. In my experience in disclosing a few hundred vulnerabilities, being upfront with that deadline is everything. What's extra great is being able to tell people like, hey, I found a vulnerability, I would love to publish this by the next conference, whatever that conference is, you can make it up, you can lie, it's fine. But just pick a security conference off the calendar that's a couple months ahead and do that, right? Provide them with regular reminders that this deadline is approaching and you have to do the thing. If you wanna say a conference or a CFP or just say a date or if you work at a company or whatever and you wanna publish these things on your company's blog, like I do all the time, let them know. You don't have to be a jerk about it, you don't have to say like, hey, I haven't heard from you in like six hours and what's the deal here? And blah, blah, blah, like you should know that like vulnerability disclosure from the receiving end is usually a pretty emotional event. So anything, like I strongly urge you to go hang out with the social engineering folks over in social engineering land and learn how to make people believe that you're on their side, I guess is the best way to put it. But yeah, you don't have to be a jerk about it. Allow for extensions on your deadline. If you have a deadline in mind, know that things happen and sometimes deadlines slip. So if you're using the conference excuse, super. That is, I think, okay, nobody cares about your conference by the way, you care about it, they definitely do not. So if you blow through it, then you have mechanisms of disclosing without specifically naming the vendor and you can give that up, right? And so they're like, well, listen, I'm gonna publish some details, but I won't say your name and I won't say who it is and I'll black out all your logos and then they'll feel cared for if you do something like that. And I don't know how to do it anyway, but try not to notice these bugs right before or right after an election because of reasons. Since 2016, the general public is aware of us, aware of our activities here. And so if you go to the news and say like, hey, I know about a vulnerability in Dominion or ESNS or whoever, and you disclose that like two or three days before an election, you're causing a bunch of chaos. Now, maybe that's what you wanna do. Maybe that's your thing, not my thing, but maybe that's your thing. I strongly urge you to not do that. The best time to disclose bugs is like today, right now. We are a year before the next congressional, national congressional elections. There's almost always an election going on, usually two or three times a year in most localities, there's an election, but then, you've got headline elections too, so be sensitive about that, please, and you don't have to cause a huge, huge tussle over your vaults. Just as inside, these three companies do have EDPs and they state in no uncertain terms the kinds of deadlines they expect, which is great. It's good for you, like you know now, and that actually gives you a huge amount of ammunition because you can tell these companies like, hey, man, you said 120 days, so that's coming up. They will still somewhat regularly ask for some extension because of something. There's like a whole recertification problem. There's a bunch of things that go into these things, right? So with voting systems in particular, definitely expect like a response pretty quick, but like an ultimate fix may be a little white ways out. I do think that like opening with like 45 days or 60 days or 90 days is a pretty good opener and fairly reasonable for like just tech in general. I know this is a fact because every open source project I disclose vulnerabilities to, they can turn them around in a day. It's always these proprietary software things that have troubles with one of that, but anyway, they have their own preferences there and good for them for saying it out loud. When you're looking at your eventual public disclosure and I promise I'm almost done, when you look at your public disclosure, just be clear on the attack scenario. Be clear on the hardware. If it's a hardware attack, if it's a radio attack, if it's a trust network attack, or if it's an internet attack, right? These are all very different kind of levels of scalability for attackers. So be clear about that. When you are disclosing vulnerabilities and when you're talking about it, you should have at your fingertips at all times the name of whatever the system is. They have several. Every one of these vendors has several of these things. They have several versions of these things. And so be sure that if at all possible, like get that version number, if you have one that you've taken apart, get the FCC IDs, those are great. Get serial numbers, anything that identifies the machine is perfect. And also, of course, note, if it's a default config versus a custom config, that can go, a lot of people can get real confused if you are talking about something that only happens in like a rare custom config. On the flip side, if there's a custom config that's like a de facto default because the defaults are nonsense or nobody uses them, then be clear about that as well. And finally, when you're dealing with the media, reporters always won't razzle dazzle, especially with this, especially with voting systems. They will, many will try to push you into oversimplifying the attack and will try to put words in your mouth and try to like lead you down a narrative that makes sense. And that, a narrative that makes sense is like the hallmark of fiction when it turns out. So be careful about that. Journalists don't usually control their own headlines. And so you might have a great experience with a great journalist and then you see a headline that is totally wrong. And well, that's the editor's problem. Clicks gonna bait, I guess. When you disclose these vulnerabilities, be prepared to deal with crazy people. There are a few of them out there that especially pay attention to things like voting machines. I'm sure you can talk to any of the voting security superstars that are at this event and ask them about the crazy people that they've interacted with. And just finally, like your bug is beautiful. It is beautiful and unique and it is special. And because of that, you are incredibly biased about your bugs. So just keep that in mind. When someone tries to talk you out of, trying to lower a CVSS rating or wants to say like, well, that's not actually really how it works. Like try to listen to it. It's very hard. Sometimes it's hard to hear. Just like it's hard to hear that your software is vulnerable. It's hard to hear that your bug kind of sucks. So just keep that in mind. If you want any help on any of this, ask me, I'm a guy who does this all the time. You can write to me, I rep seven. You can find me on Twitter, my DMs are open. And with that, thank you so much, I'm done. So I'll be around on the Discord and happy to talk about your cool, cool vulnerability.