Transcript

(Editor's note: transcripts don't do talks justice. This transcript is useful for searching and reference, but we recommend watching the video rather than reading the transcript alone! For a reader of typical speed, reading this will take 15% less time than watching the video, but you'll miss out on body language and the speaker's slides!)

[APPLAUSE] Hello. My name is Elle. And today, I'd like to talk to you about elections, interference, and security. Are there any Star Trek fans in the audience?

Whoo!

We've been treated to quite a few of the pictures, and this is no exception. "Starship crews are prohibited from interfering with the internal development of alien civilizations and should not impose their own values or ideals on them." Now, this is paraphrased from Prime Directive off of Wikipedia. And we can think of this as "thou shalt not interfere."

Let's do a quick exercise. Raise your hand if you plan to vote in your state's next election? Oh, a good number hands. We've got some good civic duty in this audience. All right. Now, keep your hand like this. I'm going to have you raise them again. I'm sorry. Go ahead. You would vote even if you knew voting technology was completely insecure. And as a result, you knew other countries could control your elections.

What is your time worth to you? Some hands going down. All right. Now, raise your hand if you would volunteer to improve elections' integrity. That's a good number of hands. It might be easier to get involved than you think. We'll come back to this later.

So who am I? So I was born in Seattle, and I attended a four-year university in Tacoma. I worked in business operations before I took a year learning to code at Ada Developers Academy. And I transitioned to a full-time, full-stack software engineer last year from my internship at Avvo. [SPEAKING QUIETLY] I see you. I see you up there.

So why am I giving this talk? Right? In the Venn diagram of junior developers where I live and elections officials, my move into coding means that we share a lot of technical milestones here in the middle. Let's do a timeline comparison.

So while I was creating my first repo at Ada in August 2016-- Fizz buzz, ah, those were days-- elections officials were receiving a flash nationwide advisory from the FBI because elections data systems in two unspecified states had been breached. So while I was taking my first steps to understanding code, elections officials were taking their first steps toward understanding the vulnerabilities in their elections infrastructure, right?

In December 2016, I was planning my alumni capstone app. And this app required me to think about things like security and authentication. And it made me start to think about the security of apps that I use in my day-to-day life, right? How secure are the things that have my financial information, my health information? How strong and robust are the systems that I rely on?

This is also December 2016. Elections officials were finding out the Elections Assistance Commission, which states rely on for testing and certifying voting systems, had been hacked. This is courtesy of Tech Crunch, by the way. I told you there would be Star Trek.

So the EAC also manages the Voluntary Voting System Guidelines or VVSG. These are standards voting machines can be tested against. And at this point in time, there had been no major updates to the VVSG since 2005. At this point, elections officials and I are realizing that the systems that we rely on aren't infallible.

In February 2017, I started my Ada internship at Avvo. My mentor at Avvo was a senior developer with a decade of experience in this field. And so if I was confused or didn't understand what was going on, I could go to him for help. I also set up one-on-ones with the other Ada intern-- they took two of us-- so that we could share learnings across teams.

And that February, the National Governors Association, or NGA, had a session on cybersecurity at its winter meeting. Most states went to DHS for help with the election security prior to the 2016 election. But the NGA started sharing resources for states looking to improve their security.

At this point, we're in the growth stage. We're all learning, myself and elections officials, to ask for help when we're out of our comfort zone, and we're setting up networking with our peers so that we can share information and knowledge. So in June of 2017, I officially join Avvo. And from the time I started my coding career to my first job in this industry, my path has paralleled elections officials learnings while foreign actors interfered with our elections and threatened our democracy.

So Russians targeted 21 election systems, US official says. This comes from testimony given to the Senate Intelligence Committee by Jeanette Manfra from the Department of Homeland Security. At this time, states still don't know if they're among the 21 targeted because names hadn't been released and wouldn't be for months.

Manfra and other officials testifying on Wednesday said US elections are resilient to hacking, in part, because they're decentralized and largely operated on the state and local level. The common argument we hear is it's not connected to the internet. That means it's safe, right? It's decentralized. It's not connected to the internet. It's operated locally. But those things didn't protect us.

So US intelligence agencies have condemned Russian actors for hacking and/or probing election systems from at least 2016 on. So if we want to think about election security as a critical component of our society, elections infrastructure in its current state is a single point of failure for US democracy. So let's take a look at the state of things with literal unit testing.

Let's talk about DEF CON's Voting Village. Oh, yes, it's going to be good. Just let it wash over you. So DEF CON is a hacking conference that's been going since 1993. And last year, it was held in Las Vegas from July 27 through 30. About 25,000 attendees had an opportunity to hack on machines at the Conference's first Voting Village.

It had the support of the Department of Homeland Security, the National Institute for Standards and Technology, congressional Cyber Caucus reps-- I believe it was Hurd and Langevin-- and the National Governors Association, which we talked about doing their peer-to-peer sharing. Also encouraged to attend, were elections officials, right? And for many of them, this was the first time that they got to really study, on a close level, the machines that they operate and are responsible for every election, which is terrifying.

So the majority of the voting equipment came from markets like eBay. Keep this in mind as we go over the findings. This will be important later. And while they tried to emulate a back-office environment, they unfortunately were not able to include back-end provisioning and registration systems, which is a shame because those are the systems that were specifically targeted by Russian actors.

However, we have to start somewhere to make a case, and it's quite the case. So there were over 25 pieces of equipment tested at the Voting Village. We're only going to go over five of them-- The AVS WINVote DRE, the Premier AccuVote TSx DRE, the ES&S iVotronic DRE, and two PEB units that come with that one specifically, the Sequoia AVC Edge DRE, and the Diebold ExpressPoll-5000 ePollbook.

So DREs are basically like your standard plug-and-play machines. Think of them as, like, there's a big box. It's a touch screen. You go up, you vote, and it saves it to local memory. That's a DRE. PEBs are basically portable memory packs. They're kind of smaller than a Nintendo Switch, right? There's two of them that come with the ES&S iVotronic, specifically.

And the ePollbook is basically just it replaces a paper, like, lists of registered voters. OK? So now that we're set up, let's start at the end with a summary of the findings. By the end of the Conference, every piece of equipment in the Voting Village was effectively breached in some manner. And it wasn't even that hard to do.

Participants with little prior knowledge and only limited tools and resources were quite capable of undermining the confidentiality, integrity, and availability of these systems. So let's start at the top, shall we, with passwords. So the AVS WINVote had an unchangeable, universal, admin password, depending on your machine, admin or A-B-C-D-E. You'll very quickly realize that the WINVote, which was in use from 2003 to 2014, is, like, consistently the last pony to cross the finish line amongst the machines that were tested.

It was also Googleable. The WINVote password was Googleable. You can find it and the config passwords for that ES&S iVotronic online. The Premier AccuVote TSx had a changeable .ini with passwords, users, and device modem configs. And the Diebold ExpressPoll-5000 default credentials-- very difficult to guess. User was 1 and pass was 1-1-1-1-- mistakenly were left online by officials. In this case, they were on acceptance test guidelines that were posted online by the Maryland State Board of Elections.

Let's talk about sanitization and encryption. So the Diebold ExpressPoll-5000 had an unencrypted SQLite3 DB with, quote, "literally all the information." That quote is courtesy of hacker TJ Horner from the post-Village write-up on GitHub. And it, like, truly included all the information-- names, addresses, your party affiliation, all the way down to like your last four digits of your social security number. Wrong. Like, on these DBs.

The DB on a memory card that was held in place with one screw. Not a security screw, a Phillips head screw. So it would be very easy to orchestrate a data exfiltration attack if you wanted to. This is problematic because one express poll had 650,000 live voter registrations on it from Shelby County, Tennessee.

Someone at the Voting Village kind of, you know, flagged down one of the conference workers and said, hey, is this part of the drill? The answer is no. They pulled the machine very quickly from the floor as they started the disclosure process for Shelby County. But 'member where I said these machines came from? Before the Voting Village purchased this machine, 650,000 people's information was essentially for sale on eBay.

Moving on. The Sequoia AVC Edge had no encryption whatsoever. Just like none. And the ballot info was uploaded in plain text. And the AVS WINVote used WEP-40, and in some cases, 104-bit encryption. So you could have worst or worse, really, depending on what you wanted. So 40- and 104-bit, both of those were declared deprecated by the IEEE in 2004.

Let's talk about updates and patches. So one file on the Sequoia AVC Edge video output firmware was last updated in 1989. That's not a typo. The AVC Edge and Diebold ExpressPoll-5000 do not employ signature verification for firmware updates. So they are vulnerable to firmware injection exploits.

The Diebold ExpressPoll-5000 runs on Windows CE 5.0. So I actually Googled this when I started doing research for this talk because I was, like, I've never heard of Windows CE 5.0. So mainstream support for this thing ended in October 2009, and extended support ended in October 2014. This machine is still in use. And on top of that, this machine also doesn't validate software updates, so it is vulnerable to bootloader injection attacks.

This is my favorite one. Let's talk about the AVS WINVote for a moment. You'll know, I didn't say unsecured Wi-Fi, I said the AVS WINVote. So the AVS WINVote was transmitting votes over always-on, unsecured Wi-Fi. One more time. [LAUGHTER] So I don't think I got that. The AVS WINVote was transmitting votes over always-on, unsecured Wi-Fi. And it had a specific IP address which was easily detected by a network tool like Wireshark.

There was a 2003 vulnerability that allowed admin access via Metasploit payloads. This has been present since 2003 and was never patched. You will remember that this machine has been used from 2003 to 2014. So this vulnerability has essentially been there for the machine's entire voting life. Which is a problem because admins could read and update the voter DB near the machine screen locally and turn the machine off.

You could change votes, and there was no record of it. You could just totally burk a machine if you wanted. Actually, if you wanted to denial-of-service attack a whole set of AVS WINVotes at a polling station, you can do that without necessarily getting caught because the wireless range for this thing is 150 to 300 feet.

Though, if you're not feeling like doing your, you know, hacking from the parking lot of the polling station, you could spend $50 to get a high-gain antenna, and then your range becomes 1,000 feet and walls don't count. So not only did Voting Village participant Carson Sherman never touch the machine he hacked, it didn't take him long to get in either.

The reason that it took me 90 minutes was not that I had to buy a USB keyboard, but that I went to a Barbara Simons talk, which took 60 minutes. And then there was 20 minutes of Harri Hursti's introduction to the Voting Machine Hacking Village, give or take a few. So it essentially took him 10 minutes to break into a machine that was used in major elections in 2004, 2008, and 2012. Let's break that down real quick.

Here's a good pie chart for you. Time spent not hacking

[LAUGHTER]

Time spent hacking. So there were other vulnerabilities that were detected during this Voting Village, like unprotected USB ports. Most machines had a minimum-- a minimum of one. One machine had a security screen that was so large and so private, that if you wanted to tamper with the USB on the back of the machine while you stood there voting, no one would notice. It was the AVS WINVote. [LAUGHTER]

The ES&S iVotronic PEB accumulator units did not have blown security fuses. So manufacturers often blow security fuses to prevent firmware extraction. And there are two types of PEB units that come with the ES&S iVotronic DRE. So there are green supervisors, and those essentially just start and stop elections on the big DRE machines.

They're just, like, OK, yes, start the election, stop the election. Those had their fuses blown. But there are also red accumulator PEBs that actually collect information off of local memory, like, collect voter data and authorize specific people to vote. Those didn't have their fuses blown. So they did, in fact, extract firmware off of them during the Voting Village.

The AccuVote TSX could be bricht by removing one socketed EEPROM chip. So the chip is hooked up to the battery controller, and it's not soldered in place. It's just socketed. Like, you do have to get the back panel of the machine open. But if you had access to the warehouse where things are being kept, you could just get in there and then pull out all those chips. And that's it, all of the machines are done.

We also have really bad manufacturing supply chain failures. So we do not fully control our pipeline for building these machines. Members of the Voting Village found-- when they were looking in the guts of the machine-- that there were parts made in other countries. Manufacturers of these voting machines can contract out and subcontract out and often do. And it would be very easy for somebody to tamper with something at a very low level while the machines are being built and put in a backdoor.

The argument that our machines are safe because they're not connected to the internet doesn't count if the machine was compromised the entire time. So what is the outcome of these findings, right? So the full Voting Village report dropped on October 10, 2017, but the findings had already made an impact.

The EAC quickly approved a new set of voting guidelines. The committee meeting was called and chaired by Kent Rochford, who was at that time, the acting Director of the NIST, one of the groups involved in DEF CON's Voting Village. So VVSG 2.0 is five pages long, and there are 15 principles in total.

It talks about things like accessibility and physical security and software updates and detection and monitoring and usability. It is a best-practices cheat sheet, and as a junior, I found it very easy to read and understand. The US Department of State may have gotten off to a slow start, but while it took months following the report's release for a response at the federal level, at the state level, people flipped out.

State officials took the findings and the release of VVSG 2.0 very seriously, and they moved to address their elections' problem areas. So Rhode Island and Colorado adopted risk-limiting audits for verifying election results. Currently, there's about a dozen states using machines of some sort that do not have audit capabilities.

West Virginia added an infosec expert with top national security clearance. Something like 30 ish elections officials in different states now have some form of clearance. But multiple states have moved to get an infosec expert in-house so that when they bring them something like, OK, we have three problems with our machines, that infosec expert with that security clearance can say I can't tell you why, but you have to fix this one today.

Illinois now requires mandatory cybersecurity training for state employees. And Washington state participated in a threat intelligence sharing network pilot. So Washington state was one of the 21 states that was targeted, and they didn't know for the longest time. And part of the reason that they participated in this network pilot was that so that they could improve communication between the federal government and states, so this didn't happen again, so that everybody was on the same page.

Virginia was among the states that had elections coming up that November-- November 2017. And with less than two months to go, their elections board threw down. One of the most drastic steps was a decision by the Virginia Board of Elections to order 22 counties and towns to adopt all new paperback voting machines before November.

The board decided that the paperless electronic equipment they had been using was vulnerable to attack and should be replaced. And they made this pivot in part because of the findings from DEF CON. This summer, hackers at a convention in Las Vegas easily broke into some of the paperless voting machines used in Virginia, which is one of the reasons the state banned them so abruptly.

Keep in mind, this was a state that was using the AVS WINVote until just before an election in 2015, when they finally pulled them. So it's not a question of whether or not we can move quickly and pivot quickly, right? So what is the takeaway here?

People care when they understand. We know elections officials care, especially about what goes on in their own backyard, but they don't always understand. Know who else cares? Voters. While other factors such as the perceived competence of poll workers or the proximity to the voting process seemed to affect voter confidence more, we know from anecdotal evidence that technical issues can be a huge pain point.

And guess what? You are voters. You are voters, and this matters to you. Right? Hands went down when I asked who would be willing to vote in technologically unsound elections. Your confidence was affected. This is your pain point.

This is your pain point. This needs to be an ongoing conversation between the tech community and elections officials. Because when we address those gaps in communication, it clearly yields positive results for our technology and our democracy. It's up to us to bridge that gap.

So this is a non-exhaustive list of groups that are good starting points for volunteering. For example, I spoke with Dr. Joseph Lorenzo Hall at the CDT. He is one of the authors on the Voting Village report. And he told me that they're working to establish direct avenues for the infosec community to get involved with elections integrity. That said, if you're not interested in doing a group, much like routes into technology, you can forge your own path and go it alone.

If you do that, get a lawyer. You will need one. Harri Hursti and Margaret MacAlpine, two other Voting Village report authors, stress that anything we do and everything we do has to be above board and in full compliance of the law. There are actors who would prefer to maintain the status quo. We cannot allow them to set a legal precedent to block this work. Everything has to be above board.

You specifically need a lawyer whose practice areas are at the intersection of technology, state, and federal voting laws. You can also spread knowledge of election laws in your state, especially within tech communities. It's a lot harder to intimidate people with litigious threats if they have shared understanding of their legal boundaries and are empowered to operate within them.

You could volunteer as a poll worker. This is often very difficult work, but we need people on the ground with tech savvy and the ability to work dynamically with arcane systems. Right? You can take your skills that you learned working on your company's ancient monolith and go work and apply it directly to ancient election systems. Oh, look at that.

You can also help DEF CON 26 get voting machines. So DEF CON 26 is this summer, and eBay voting machine resellers have already received threatening letters from voting machine vendors. If you want to help with this, reach out to Jake Braun at Cambridge Global Advisors. He is the fourth author of the Voting Village report that I spoke to for this talk.

And finally, no matter what you do, involve junior devs in your work. We are closer in level to non-technical folks than experienced technologists. No one wants to be tech shamed even if it's totally unintentional, and that goes double for elections officials who are already stung by a lack of information during Russian hacks.

You need officials to trust you so they will bring you their concerns. So solicit feedback from your junior coworkers to help you hone those technical communication skills. Something as simple as, hey, does this sound pretty good. I'm not condescending, right? Something that basic will work.

Your communications with elections officials should look a lot like VVSG 2.0. Engage literal juniors. We see very strong engagement from generation Z developers. They come directly after millennials. And for many of them, our elections has been under direct threat from interference since before they had the right to vote.

It's worth noting that not only do the University of Houston Cybersecurity Club participate in the Voting Village, but they had their findings included on the post-Village write-up on GitHub. Remarkably, many of the hackers that stayed in the Voting Village for a considerable amount of time were young-- between the ages of 16 to 19. This kind of civic infrastructure hacking may be a promising way to reach out to younger elements of the information security community. DEF CON recognizes this, and we should, too.

And finally, diverse backgrounds improve breadth of experience. So I work with a junior developer who also came through my program. Before she moved into tech and coding, she worked for a senator's office in another state. She probably knows which agency maintains vote reporting in her old city.

If we step, for a moment, outside of our voting machine scope, somebody could cause significant damage to an election just by changing the numbers on that site, right, making it look like a candidate got 100% of the vote or switching the numbers back and forth. I want her on my elections team to provide insights that I don't have and wouldn't think of otherwise.

And it's not just direct experience that's important. I learned to code amongst neuroscientists and teachers and nurses and people with top US security clearance, surprisingly, and veterans and chefs and social workers. Coders from their 20s to their 50s, woman and non-binary and trans folks, people of color, we can't afford to mess this up.

And we need people in this work who don't look like us and don't think like us and weren't trained like us because they'll catch and raise the errors that we'd otherwise miss. We need everyone involved because this affects everyone. Now, go out and make it so. So I'm Elle. This talk will be posted up on my GitHub. There is a bibliography. You can check it out if you're interested in getting involved. Thank you.

[APPLAUSE]